Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

disk io is often the bottleneck in the database area.

SQLite usually gets used in situations where the data easily fits into memory (multiple times). It isn't really postgres ;)



Right. But by no fault of Postgres either because disk-based io offers durability and in-memory classically does not. Apples and oranges.

In fact all the recent discussions of "performance" for RDBMSs has to be understood in terms of "what's being sacrificed for one or more aspects of ACID?". RDBMS technology is incredibly mature and optimisations that keep the ACID aspects intact are also incredibly difficult now. Marginal returns.


You're of course right, what I meant to say: In the typical use cases of sqlite the whole db content usually is cached in RAM anyway, so 50% faster really is 50% faster. I found that out quite recently when researching whether caching pythons sqlite in a web app prototype would make it faster: It won't, It's usually completely cached anyway.


This is no where near true, might be true for spinning disks, but we haven't even really started to optimize RDBMSs for SSDs.

Also sqlite is IO and ACID compliant, it's just that the data generally fits in RAM where as many Postgres installs have data that doesn't fit in RAM.


There is still plenty of room for improvement. See eg http://arxiv.org/abs/1210.0481




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: