Live data from Hacker News

Database internals are becoming less important than developer experience

planetscale.com

21–30 of 76 posts

Re: Database internals are becoming less important than developer experience

#21
post #9

> MySQL, MongoDB, Firebase, Spanner; there has literally never been a better time to be a database user at any level of complexity or scale. But there’s still one common thread (ha!) among them – the focus is on infrastructure, not developer experience. It was my impression that everyone picked (and still picks) MySQL, MongoDB, and Firebase _because_ they were the easiest to use. It seemed like developer experience w…

> It was my impression that everyone picked (and still picks) MySQL, MongoDB, and Firebase _because_ they were the easiest to use. I've found that to be the case, except for enterprise development, which has different concerns than how quickly code gets written to use a database.

Are you saying that enterprise developers pick MySQL, MongoDB, and Firebase for other reasons?

Re: Database internals are becoming less important than developer experience

#22
post #11

> MySQL, MongoDB, Firebase, Spanner; there has literally never been a better time to be a database user at any level of complexity or scale. But there’s still one common thread (ha!) among them – the focus is on infrastructure, not developer experience. It was my impression that everyone picked (and still picks) MySQL, MongoDB, and Firebase _because_ they were the easiest to use. It seemed like developer experience w…

I can't imagine any scenario under which a reasonable person of at least median intelligence would perceive MongoDB as "easier to use" than Spanner, unless their entire experience with Mongo was they put one trivial JSON doc into an M0 cluster and got it back out later. Every practical aspect of MongoDB is a complete shitshow, from sharding to backup to failover.

"Sharding" "Backups" and "Failovers" are NOT "practical" aspects of any database. They're theoretical. Most databases are not big enough to need sharding. Most backups go unused. Most failover happens automatically, totally managed by your hosting provider.

You know what is practical? Schema design. Query language. That's what made MongoDB super popular; no schemas to worry about. A query is just '{ firstName: "John" }'.

I cannot emphasize this enough: I cannot summon even a milliliter of desire to care about whether Mongo's way of doing these things is actually "better" or "worse". But it is what made it popular.

Re: Database internals are becoming less important than developer experience

#23
post #15

As a developer, I have to say that sqlite gives me the best experience. Everything else pales in comparison. Create a database? sqlite3 mydata.db Where is the database? In the current directory How is it structured on disk? It's a single file How do I backup the DB? cp mydata.db /my/backups/mydata.db Do I have to install a server? No Do I have to configure anything? No During setup and deployment I usually I dabble a…

This feels like kind of a silly comparison. SQLite can't do most of what makes modern databases difficult/valuable. As an example, if you replace your above example with a CSV file, you'd get the same output, right?

I describe the differences between sqlite and mysql, postgres, oracle etc that are the reason why I like sqlite best.

If for you there are specific differences that make you chose some other db, let us know.

Re: Database internals are becoming less important than developer experience

#25
post #23

Earlier quoted context omitted.

This feels like kind of a silly comparison. SQLite can't do most of what makes modern databases difficult/valuable. As an example, if you replace your above example with a CSV file, you'd get the same output, right?

I describe the differences between sqlite and mysql, postgres, oracle etc that are the reason why I like sqlite best. If for you there are specific differences that make you chose some other db, let us know.

I remember that back in the day getting Postgres up and running was an enormous chore - SQLite was definitely the easiest but even MySQL was a walk in the park compared to Postgres. But Postgres is simply amazing - it is entirely transparent about the metadata it's storing to assist querying and has mature tools available to help you optimize queries. The only "big" one that I haven't used is Oracle mostly because the price makes it insanely unreasonable for small companies. Out of MySQL, SQLite, MSSQL and Postgres I'd have to say my favourite is Postgres due to compelling the least number of hair-pulling frustrations and having absolutely pristine documentation - followed closely by MSSQL though MSSQL sometimes seems to go out of its way to have an incompatible dialect.

Re: Database internals are becoming less important than developer experience

#26
post #15

As a developer, I have to say that sqlite gives me the best experience. Everything else pales in comparison. Create a database? sqlite3 mydata.db Where is the database? In the current directory How is it structured on disk? It's a single file How do I backup the DB? cp mydata.db /my/backups/mydata.db Do I have to install a server? No Do I have to configure anything? No During setup and deployment I usually I dabble a…

calibre uses sqlite and it doesn't support hosting the db on a network drive. https://manual.calibre-ebook.com/faq.html#i-am-getting-error... i guess that's a bad -dev- user experience?

You can certainly host it on a network drive if the network filesystem has the right features and behaviour.

The same goes for a local filesystem. Sqlite has certain features it requires the filesystem to have. That is independent of how that filesystem stores the data physically.

Re: Database internals are becoming less important than developer experience

#27
post #15

As a developer, I have to say that sqlite gives me the best experience. Everything else pales in comparison. Create a database? sqlite3 mydata.db Where is the database? In the current directory How is it structured on disk? It's a single file How do I backup the DB? cp mydata.db /my/backups/mydata.db Do I have to install a server? No Do I have to configure anything? No During setup and deployment I usually I dabble a…

This feels like kind of a silly comparison. SQLite can't do most of what makes modern databases difficult/valuable. As an example, if you replace your above example with a CSV file, you'd get the same output, right?

> with a CSV file, you'd get the same output, right?

Not when you have threads.

Re: Database internals are becoming less important than developer experience

#28
post #6

> NoSQL databases are maturing, for sure – we’re starting to see support for transactions (on some timeframe of consistency) and generally more stability. 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. So funny to me that NoSQL boosters have only recently understood that designing sane schemas and knowi…

To be fair, relational algebra is hard. That being said: going back to 1970 to read the original "A Relational Model of Data for Large Shared Data Banks" by Codd (the paper which started the relational-database + normalization model) is incredibly useful. But yeah, all of this debate about "how data should be modeled" was the same in 1970 as it is today. ----- SQL doesn't quite fit 100% into the relational model, but…

I had a specific class on relational algebra in uni and it is up there with algorithm design and analysis in the realm of classes that actually provided me the most long term value.

Relational algebra is a lot easier once you start viewing it as relational algebra - a declarative expression of intent that can be manipulated and re-expressed similar to other purely mathematical statements. Then, when performance tuning becomes the watchword, you take that flexible expression and slice and dice it according to how the DBMS you're working with requires to align it with performance. You always want to think of your queries as complex summoning spells that draw in different necessary resources in some particular patterns and then impose an expression form on that blob of data - then you'll skate through all things SQL.

Re: Database internals are becoming less important than developer experience

#29
post #15

As a developer, I have to say that sqlite gives me the best experience. Everything else pales in comparison. Create a database? sqlite3 mydata.db Where is the database? In the current directory How is it structured on disk? It's a single file How do I backup the DB? cp mydata.db /my/backups/mydata.db Do I have to install a server? No Do I have to configure anything? No During setup and deployment I usually I dabble a…

Is there a wrapper to treat a database like its an sqlite database (a file) to simplify to the same level as Sqlite? This may at least simplify some issues. Doesn't matter whether its backed by a local database running in a container or by a remote one.

Re: Database internals are becoming less important than developer experience

#30
That does make some sense, especially for databases that have been around a while. Lots of internals were written with hard drives in mind rather than SSDs, much lower amounts of memory, and so on. On the other hand, it's nice when your database works well in even a very limited or old environment.
Post reply on HN