Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Database internals are becoming less important than developer experience

planetscale.com

Post reply on HN
Print view View original

11–20 of 76 posts

Re: Database internals are becoming less important than developer experience

#11

Post by jeffbee »

eatonphil wrote: post #5

> 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.

Re: Database internals are becoming less important than developer experience

#13

Post by fabian2k »

Understanding a limited amount of database internals has been very useful to me. There is one aspect of using databases that you simply cannot abstract away and that is performance. If you ask your database a question in a way it is not suited to perform or that isn't supported by indexes performance is not going to be good.

And these performance differences are not small once your database has a decent size. And if you tables are really large it's not a question of fast or slow but fast enough or so slow it's indistinguishable from the database being down.

Of course to some extent you can simply throw hardware or money at the problem. This certainly works for smaller inefficiencies, but sometimes knowing the database will give you orders of magnitude better performance. Hardware and money also don't scale indefinitely.

Re: Database internals are becoming less important than developer experience

#15

Post by TekMol »

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 while with the whole GRANT *.* ON localhost IDENTIFIED BY PASSWORD or something. How do I do that with sqlite?

    It just works
Do I have to close / protect any specific ports?

    No, it's just a file
Which field types should I use for ... ?

    None. It just works.

Re: Database internals are becoming less important than developer experience

#16

Post by abanayev »

fabian2k wrote: post #13

Understanding a limited amount of database internals has been very useful to me. There is one aspect of using databases that you simply cannot abstract away and that is performance. If you ask your database a question in a way it is not suited to perform or that isn't supported by indexes performance is not going to be good. And these performance differences are not small once your database has a decent size. And if…

At some point, DBaaS systems should be able to understand and make inferences about your use cases, to the point where indexes and other performance optimizations are automated whenever you register a new query or something. This would be the new era of database systems, and as the article points out is increasingly true about all “infrastructure” concerns.

Re: Database internals are becoming less important than developer experience

#17

Post by waynesonfire »

TekMol wrote: 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?

Re: Database internals are becoming less important than developer experience

#18

Post by void_mint »

TekMol wrote: 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?

Re: Database internals are becoming less important than developer experience

#19

Post by cl0ckt0wer »

wmf wrote: post #12
cl0ckt0wer wrote: post #3

I would think that having bad internals would create a bad dev experience.

Unfortunately MongoDB proved the opposite. You don't notice the data loss and schema problems until later.

That is a pretty bad experience in the long run.

Re: Database internals are becoming less important than developer experience

#20

Post by eatonphil »

jeffbee wrote: post #11
eatonphil wrote: post #5

> 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.

With the understanding that Mongo _is_ popular I think you're making my point. Though I have no clue if most people who choose Mongo evaluate it against Spanner.
Post reply on HN