Should I Change My Database Engine?

This post is not about what what SQL engine is best. Just like programming languages or tech stacks these days, database engines are more or less a commodity. It's unlikely that there is some engine that can do something that another one can't unless you have some pretty esoteric requirements. Most of the startups we've come across can switch between the common options without skipping a beat on production (that doesn't mean it's necessarily trivial - just possible and well defined).

So what's the difference?

There are two main approaches to data out there - relational and document-based. Relational is your classic MSSQL, MySQL, Oracle, etc. Document based is the "newer" wave of MongoDB, Redis, Firebase, DocumentDB, etc. Postgres is kind of in the middle. The big difference is data integrity - if you delete something in one table that depends on something else in another table, what happens? Should this even be allowed?

But this post isn't even about that. Suffice it to say that the first choice to make is just the approach - should you go relational or document? And believe it or not, even though document-based databases are the "new hotness", most startups do better with relational databases because the data they're dealing with is, well, relational. So we're focusing on that in this post.

So why migrate?

If you don't have some pretty edge case requirements that point you to a specific database provider (yeah, there are some differences and some are better at some things than others), it comes down to the existing state of your database and cost.

Here's our rule of thumb for when a startup comes to us with a mess in their product and asks to point them in the right direction.

Does your database look like the picture at the top?

If so, great - whoever put together your database is aware of primary and foreign keys. If your database engine is MSSQL or Oracle or MySQL or whatever and you're happy with everything else, leave it alone.

Does it cost a reasonable amount to host it?

MSSQL and Oracle typically cost more to host and maintain. Not always, but usually. But the cost difference isn't significant until some size, requirements, replication, etc. If you're happy with your costs and you have backups going and nothing in your immediate roadmap that will considerably change the demand on it, leave it alone.

Does your tech stack talk to the database in a sane way?

Any tech stack can talk to any database, but depending on the tech stack your team chose, some are easier than others. For example, do you use an ORM (good) or hard coded SQL statements (bad)? Does a good ORM exist for your tech stack and database choice? If you're using a well-supported ORM, leave it alone.

If you answered YES to all the questions above...

If you have a relational database and your diagram that looks like the one at the top and is enforced in your schema (you can actually see foreign keys defined in your database), then the database engine you have is fine - if a team or a developer is suggesting a migration, push back, ask them to justify it and talk to us and we'll help you navigate. Remember that migrating is sometimes a long and arduous process that always costs money.

If you answered NO to any of the questions above...

Talk to us and we'll help you make the right decision. It might still not make sense for you to migrate. A big difference between a developer or a development team, even a senior one, and a CTO is we take other factors into account. A developer will almost always suggest tools and technologies they are most comfortable with - that's OK and expected. If you are switching developers and the new team is telling you to migrate tools or databases, always consider that with a grain of salt.

CTOs consider many other factors - your near-term roadmap, your long term roadmap, security needs, legal needs, costs, architecture, future integrations, cost of hiring future teams to support your application (expertise in some stacks comes "cheaper" than others), stability, maintenance, and other business requirements that developers don't think about.

Talk to us if you want some guidance making a good choice the first time around (or at least the second) or qualifying the recommendations of a new team or developer. We are always happy to help! Reach out at info@fastcto.com