Live data from Hacker News

Database internals are becoming less important than developer experience

planetscale.com

71–76 of 76 posts

Re: Database internals are becoming less important than developer experience

#71
post #65
post #61

Earlier quoted context omitted.

We've been using sqlite as our only datastore for the last 5+ years. There are a lot of fun little tricks you learn along the way. The most important one is to ignore all the naysayers who claim it won't scale. I can easily saturate any IO subsystem by way of SQLite. At first you may think it's impossible, but then you start to go outside the lines a bit. You start by turning on WAL. That helps a lot... But then you…

How do you aggregate the data and query among all those databases? Doesn't it incur huge costs? Does sqlite support this natively or are you basically treating it as text files of data per user and don't need complex queries in the first place?

Sqlite has it natively. After connecting to user1.db just execute this query:

ATTACH DATABASE user2.db AS user2;

Now you can use user2.tablename in any query just as if was part of user1.db

Re: Database internals are becoming less important than developer experience

#72
post #53

Earlier quoted context omitted.

That is why I mentioned the "worst case". You are describing the best case. Where everything is in a cache close enough to the CPU that it is not impacted by the other CPUs data access.

I'm talking about relatively simple cases like spinning up a phpbb3 (web forum) instance. The minute you have multiple users writing comments at the same time from different apache/php instances is the minute your SQLite database starts to fall over. Every write (aka: every comment post) is an exclusive write on SQLite. A full lock that prevents other processes from reading. (Ex: User#1 writes a comment, but User#2 h…

Check SQLite WAL mode: single write, multiple simultaneous reads. https://sqlite.org/wal.html

Re: Database internals are becoming less important than developer experience

#73
post #12

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.

> You don't notice the data loss

Wait, is that a feature or a bug?

Re: Database internals are becoming less important than developer experience

#74

Earlier quoted context omitted.

I think GP was pulling apart "everyone".

Ah. To clarify I meant that it was my impression that most people that pick one of those dbs pick it because they are easy to use.

Yes but obviously not "everyone picks [those DBS]"

Re: Database internals are becoming less important than developer experience

#75

~hello everyone, author here~ I know posts with ThOuGhT LeaDeRshIp titles like this are usually annoying, but I thought it would be interesting to write down some of the lessons I've been gathering as I've spent more time covering and using specific databases. My background is in data science / analytics with a couple of years of more traditional full stack here and there. Broadly we've seen this pattern with infrast…

I think you bring up some good points, but it's factually incorrect to state that mongodb is not ACID compliant (it has been since its 4.0 release). The way to win is not by hyperbole and lies. It's to your point by focusing on developer experience.
Post reply on HN