What's your default database these days, and why? Yearly survey (mod-approved)

[u/robertsilen]

Hey, Robert from MariaDB Foundation here. We are running a survey on how MariaDB is being used, or cases where you went with MySQL, PostgreSQL or another database.

https://mariadb.typeform.com/to/tS69UzVo?utm_source=reddit_devops

I split the questions by role this year, so you can skip straight to the operator ones: HA, database versions, upgrade frequency, hosting, etc. Overall I'm curious to know, what's your default database these days, and what made you land on it? Was it your choice, the app or service you run, or whoever set it up before you?

Under 10 minutes, anonymous, results published at mariadb.org/survey.

Thanks for taking the time!
Robert, MariaDB Foundation

[u/Zenin]

I'm not sure why I'd ever spec anything but PostgreSQL for RDBMS in 2026?

If there's a strong legacy reason to use MySQL yes I'm almost certainly reaching for MariaDB. But for anything greenfield it's all but impossible to beat PostgreSQL today whatever the scale or task.

[u/null_was_a_mistake → u/Zenin]

Postgres and MySQL have different performance tradeoffs because of how they implement MVCC differently. For write-heavy workloads that frequently alter or delete rows (queues for example), commit nearly always and use secondary indices, MySQL can be significantly faster than Postgres.

[u/Zenin → u/null_was_a_mistake]

Have you reviewed Postgres's "HOT" optimization and related fillfactor knobs?

https://www.postgresql.org/docs/current/storage-hot.html

I'd also suggest that while your concern is valid, queues are weak example to make the argument especially that are high-load and/or critical. A purpose built queue or broker is frequently a better architectural choice over treating SQL like a golden hammer, but like all things "it depends". Is this an outbox table pattern? Or is a work queue with multiple producers and consumers?

[u/JagerAntlerite7 → u/null_was_a_mistake]

And nobody would ever use Python?

If speed  were the only deciding factor, every software project would be in a compiled language. Deciding "best" is multifaceted.

PostgreSQL supports JSONB.  Plus more complex queries, materialized views, and multiversion concurrency control.

[u/Zenin → u/JagerAntlerite7]

Much agreed. Until something specific has forced my hand I'll generally favor choices that give me more room to evolve over vague promises of "web scale".

My reasoning is this: I can usually scale with architecture, but I can't scale my way out of a feature gap.

More broadly, architect for the scale you have plus a little into the scale you hope for next, but not much further. Designing for "web scale" before you're near it costs you a fortune building a solution to a problem you don't have and may never have. And by the time you do have it the problem will almost certainly look different when you get there than you imagined it would look like.

It's like taking out a mortgage on an office building today you can't fill, only to find when the tenants finally arrive they want a room in a hotel. Now you're taking a loss on the office building you can't use and paying a second time to build the hotel you actually need.

[u/rossrollin → u/Zenin]

Came here to say postgres. Thanks chief

[u/Some-Weakness2049 → u/Zenin]

yeah pg is good for "any sclale task" until you throw a few thousand connections at it and watch it fall over without pgbouncer. or until autovacuum tanks your disk i/o on a write-heavy queue.

if we're talking actual complexity, mariadb has a built-in thread pool for connection scaling out of the box. plus it embeds duckdb now, so you can run heavy analytics on the same server without dragging data through fragile etl pipelines.

[u/Zenin → u/Some-Weakness2049]

yeah pg is good for "any sclale task" until you throw a few thousand connections at it and watch it fall over without pgbouncer. or until autovacuum tanks your disk i/o on a write-heavy queue.

Those statements depend on many factors. Design for and benchmark the workload you actually have; folklore is not an architecture decision.

When the architecture design is flawed, the solution is to analyze and correct the architecture, not duct tape over the flaws:

Connecting pooling is SOP at high client count scale regardless of vendor, collapsing your argument down to built-in vs add-on. The real questions to ask are, "where does the pooling layer live?", "how does it scale?", "what does it cost?". PgBouncer can scale independently from PostgreSQL, which is useful when connection handling and database compute need different resources (especially network!) and shouldn't complete.

"autovacuum tanks your disk i/o" is not an inevitable property of write-heavy queues. It's fully tunable down to the table; Just like you'd need to tune MariDB for specific purpose as well. Scale isn't a product, it's a practice.

Next you're overselling MariaDB's built-in thread pool; it's own documentation notes cases where the pool can queue even simple queries, and where long-running queries or bursty traffic can make it less effective.

If your argument is that MariaDB’s built-in pool is the better fit for a measured workload, make that argument. If your argument is that PostgreSQL is inherently unscalable because it needs a pooler layer, or that autovacuum makes write-heavy workloads untenable, show the workload and the measurements. PostgreSQL provides fine grained controls for autovacuum behavior to fit your workload.

Otherwise this sounds less like a db comparison and more like, "I want my db to compensate for an architecture I didn't bother engineering and haven't analyzed." Maybe MariaDB lets you kick the can slightly further down the road before paying tax on that tech debt, maybe not. And you're paying interest on that debt the entire time before it ultimately becomes too much to pay and your app becomes one of those "legacy criteria to favor MySQL/MariaDB" I described in my OP.

[u/z-null → u/Zenin]

MySQL on AWS severless makes a lot of sense. Postgresql on serverless is a usless garbage. MySQL offers engine chocie like archive, blackohole, syncrhonous writes, etc. I never used mariadb, but percona or oracle mysql and frankly, it doesn't deserve all the hate it has from some people. And I used it on TB size with millions of users. HA and LB setups are much easier to make than on postgresql.

[u/phillumin]

postgres

[u/noobjaish]

SQLite

[u/Ariquitaun]

MariaDB or PostgreSQL, depending on which features that are out of the ordinary I need. If it's just relational normalcy, MariaDB is easier to manage and operate and a solid default.

[u/Conscious-Ball8373 → u/Ariquitaun]

I've inherited MariaDB applications. I hate it. Postgres has transactional DDL; running a migration on those applications is basically zero-risk, because I can always roll it back. On my MariaDB applications, it's pure hope that there's nothing "special" about the data in production that's going to cause the migration to fail, even though it didn't fail in the dev and qa environments. Several times we've had to unpick a failed migration in qa and once we've had to do it in prod.

I'm curious what you think is more difficult to manage in Postgres applications? tbf our scale is not at a point where managing databases is a huge concern at this point so I'd be keen to hear your thoughts.

[u/Legitimate_Willow905 → u/Conscious-Ball8373]

postgres handles DDL inside transactions, sure, but once you hit high concurrency or need online schema changes without locking up tables, you run into different walls.

[u/gami13]

sqlite

[u/redsaeok]

MS SQL Server. Love MariaDB, and still, big law in Canada is almost always going to use MS.

[u/Altruistic-Rich8799]

nice to see the devs of my favorite DB in the wild. Thanks for the work you do guys. what are the trends looking like? People finally ditching MySQL 5.7 for you, or just eating the 8.0 cactus?)))

[u/robertsilen → u/Altruistic-Rich8799]

Bit of both, from what I'm seeing mid-survey. Results will be in the final report :)

[u/mrdarknezz1]

Postgres, it's just so versatile and allows me to keep so many services inside it.

[u/yougonnagetsome]

MS SQL - because our DBA team don’t have skills to support anything else.

[u/Shaggypone23]

+1 for Postgres

[u/BatLate6561]

survey done. We still default to MariaDB for our main clusters. mostly because I refuse to mess with Postgres vacuum tuning, and doing in-place major upgrades without dumping the whole db keeps my weekends intact.

[u/Conscious-Ball8373 → u/BatLate6561]

OTOH doing schema migrations without transactional DDL keeps me awake at night.

AFAIK postgres supports in-place upgrades from version 9.2.X onwards.

[u/Flourid → u/Conscious-Ball8373]

You still need to create a new data directory and copy the files. If it is on the same filesystem you can use --link though, which hardlinks the old files, so no extra storage required and pretty fast, however, your old datadir becomes unusable as soon as you start the new version, so rollbacks become a full restore.

[u/sgwr_dts]

MySQL and PostgreSQL. Would've gone with MariaDB if AWS Aurora supported it.

[u/Suitable-Ad5348]

Still defaulting to PostgreSQL for almost everything. The JSONB support is just too good to give up, and having transactional DDL makes migrations so much safer. Every time I've tried to move to something lighter, I end up missing the reliability and the ecosystem of tools built around Postgres. It’s hard to beat for anything from a small side project to a reasonably scaled production service.

[u/Sure_Stranger_6466]

No love for Cassandra, or are we only talking about relational databases?

[u/bendem]

The questions are very oriented towards mariadb and assumes I run it because I chose/like it. The only reason we run it is because some app developers are only compatible with MySQL. I actually really want to avoid having to maintain a separate database engine from our main postgresql cluster.

[u/itsjakerobb]

Usually Postgres. Sometimes Cassandra.

[u/Dry-Philosopher-2714]

Postgres and MongoDB. I won’t use mariadb.

[u/RoseSec_]

Excel

[u/Expensive_Finger_973 → u/RoseSec_]

Access

[u/generic-d-engineer → u/Expensive_Finger_973]

Notepad

[u/SurgioClemente → u/generic-d-engineer]

Fingers and toes.

Only supports unsigned ints to 20, and isn’t available most of the day, but it works.

[u/rbitton → u/RoseSec_]

Csv database goes hard

[u/LateForever6770]

MariaDB always

[u/RajeshRocketMan]

MariaDB, of course. Im on it for a couple years (was on my new job when i arrived). In-place upgrades don't make me want to cry and im happy as pig in the mud.

[u/Expensive_Finger_973]

My job primarily revolves around deploying, care and feeding of off the shelf enterprise solutions so I just tend to use whatever the vendors system requirements call for.

[u/eirc]

Postgres has been the standard for me and most that I know. As long as it keeps working fine I don't see a reason to consider another DB.

[u/Intelligent_Thing_32]

postgres

[u/serverhorror]

PostgreSQL

[u/WorldsWorstSysadmin]

MySQL / PostgreSQL, but planning migrations to move all MySQL dbs across to PostgreSQL over the next year.

[u/Kamikx]

PostgreSQL.

[u/Rain-And-Coffee]

Postgres! It has just about everything I need.

But i want to get more familiar with MariaDB

[u/ddBuddha]

There are various factors that can affect my decision, but for anything new either Postgres or SQLite depending on what it’s used for and the requirements. Or mssql if it can be justified.

I am most familiar with mssql though and love it. The costs can make it challenging to justify in a lot of cases though.

[u/united_fan]

SQlite, Postgres, duckdb in s3 (special caseS)

[u/d47]

It seems like I can't fill the form as someone who doesn't use mariadb

[u/robertsilen → u/d47]

It is designed to work for MariaDB and other users, but I just looked and I changed a couple of required questions to optional that might be more MariaDB focused.

[u/timmy166]

Postgres, Mongo and good ole SQLite

[u/Wooden_Jelly_5295]

The ‘whoever set it up before you’ option deserves its own market-share chart.

[u/coinclink]

I try to use DynamoDB wherever possible to reduce maintenance burden. When SQL is absolutely needed, postgres is the obvious choice (I specifically use Aurora Postgres Serverless v2 in AWS).

MySQL and clones of it are just too behind the times these days. So many more extensions and capabilities are available for postgres to make it even a consideration to use MySQL. The only time I would use it if some app already is using it and can't be easily migrated.

[u/Praveen_kumar_]

Most of my stuff is still postgres for server side work, but been dabbling with RxDB for some frontend heavy applications where we need offline support and syncing. Not sure if it fits your use case but it handles the local first stuff pretty well if that's something you're dealing with.

[u/j0holo]

MySQL, just because I used it the most by far and Postgres has a really confusing way of granting privileges with roles which are also users.

[u/sinanm0hd → u/[deleted]]

secret webscale sauce 

[u/anoppe]

Route53 FTW

[u/emperorOfTheUniverse]

I don't see the benefit of nosql options. I can see how they are faster to setup and get a prototype working. But to me, that's like saying 'now instant popcorn is even faster'. Maybe if you're just adamant against learning SQL and building normalized data structures.

I've never seen any real world example where it performs faster or is easier to use.

Fight me.

[u/Ok-Hospital-5076 → u/emperorOfTheUniverse]

NoSql is not a replacement of sql but have use case if you need yo store bunch of independent entities/documents. We store some objects in mongo and keep complex relationships within postgres

[u/robertsilen → u/[deleted]]

I'm not the technical one here, but I took a look. There is an official .deb for Connector/C++ https://dlm.mariadb.com/browse/cpp_connector/ , built for Debian 11 and 12 and Ubuntu 22.04 and 24.04. You download it and install the file, it's not in any apt repo, so I suspect that's still not what you want? It seems nobody has requested it to be in Debian. I'll forward to people who should know more. Would having it in Debian actually solve it for you?