Even Spanner’s product page talks a lot about scale, and not very much about anything else: Another good one to note is Vitess, an orchestration layer for MySQL, which is what we work on here at PlanetScale.Īgain, the narrative centers around infrastructure – you don’t have to sacrifice scale for transactional rigidity, etc.
Aurora, which is AWS proprietary, also claims to be distributed and faster than MySQL and co. One example is Spanner, a relational data store developer at Google ( paper here) that claims to scale horizontally and infinitely (e.g. SQL scalersĮnter the “new thing” in databases, which people are calling SQL scalers – relational databases with transactional rigidity, but they scale horizontally. And, fundamentally, developers actually often liked SELECT * over something like. If you decide down the road to analyze data in a different context or another area of your application, having a schema defined can produce reliable results from changing queries. After years of working with “flexible” databases though, it has become clearer that rigidity up front (defining a schema) can end up meaning flexibility later on. NoSQL databases are maturing, for sure – we’re starting to see support for transactions (on some timeframe of consistency) and generally more stability. The problem with MongoDB, and NoSQL databases generally, is that they’re not ACID compliant (they’re eventually consistent, as per CAP Theorem), and developers actually often liked SELECT * over something like. Note: While SQL refers to the actual language used to query relational databases, over the years it has become synonymous with the concept of pre-defined schemas and relational data, hence the moniker “SQL Database.” Where things started to go wrong was scale. Before OLAP was a thing, the priority for these databases was making sure your reads were clean and your inserts worked, every time, without exception and so to do that, you structured your schemas in advance. ACID) – even though today, people use it to query data that’s less structured. They’re actually still the most popular databases in terms of usage on the planet, and there’s probably a lesson there, but for another time.įundamentally, SQL was about rigidity and transactional integrity (i.e. MySQL’s initial release was in 1995 (that’s 26 years ago), and Postgres’s was a year later in ‘96. The beginning, relational landĪn early history of databases is beyond the scope of this post, but it’s safe to say that databases were synonymous with relational data for the first couple of decades of their existence. The common thread between them all is the improvements were infrastructure focused, not developer experience focused.
To get some perspective on the shift happening in databases, it’s worth looking back at what are essentially 3 eras (at least from this perspective) of data stores.
Most database products today focus on internals # This post is going to argue that database internals are going to matter less long term developer experience is what will differentiate offerings. But there’s still one common thread (ha!) among them – the focus is on infrastructure, not developer experience. MySQL, MongoDB, Firebase, Spanner there has literally never been a better time to be a database user at any level of complexity or scale.
0 kommentar(er)
