3 ms·

Obviously if it was embeddable it wouldn’t be as fast and be subject to the same design limitations as SQLite.

by hizanberg 7y ago

pedrocr 7y ago
There's nothing about being embeddable that's a limitation. All I really want is a lib I can link to that gives me an entry point to launch the database against a given folder, with some of the tweaks the postgres config file has, and that gives me a connection back. That entry point can launch however many threads it wants and behave exactly like postgres itself. After that my app can connect to a standard postgres and take advantage of all the features and performance. We've been moving so much into web apps that optimizing for desktop apps like these is not a big concern these days. Sqlite ends up being used in that niche but it's extremely easy to run into it's limitations even in very simple personal usage. It's fine for what it is, an alternative to open(), but there are plenty of use cases where optimizing for fast open is not relevant. Here's an example of where I'd really like postgres to replace sqlite: https://github.com/pedrocr/syncer/ https://github.com/pedrocr/syncer/ I've had to add an extra caching layer because of sqlite INSERT performance. Given that I've already had to code around limitations and the schema is simple I will probably end up using a simpler non-SQL database in the future instead.
- hizanberg 7y ago
  > There's nothing about being embeddable that's a limitation. An always-running in-memory server process is going to be a lot better at concurrency than multiple embeddable libraries trying to take locks out on the same file on disk.
  - pedrocr 7y ago
    Read what I wrote. What I want is always-running in-memory. Being embeddable doesn't mean you need to have the sqlite model where several processes access the same database. None of the sqlite uses I've had required that at all.

3 ms·

Obviously if it was embeddable it wouldn’t be as fast and be subject to the same design limitations as SQLite.

by hizanberg 7y ago

Obviously if it was embeddable it wouldn’t be as fast and be subject to the same design limitations as SQLite.

pedrocr 7y ago
There's nothing about being embeddable that's a limitation. All I really want is a lib I can link to that gives me an entry point to launch the database against a given folder, with some of the tweaks the postgres config file has, and that gives me a connection back. That entry point can launch however many threads it wants and behave exactly like postgres itself. After that my app can connect to a standard postgres and take advantage of all the features and performance. We've been moving so much into web apps that optimizing for desktop apps like these is not a big concern these days. Sqlite ends up being used in that niche but it's extremely easy to run into it's limitations even in very simple personal usage. It's fine for what it is, an alternative to open(), but there are plenty of use cases where optimizing for fast open is not relevant. Here's an example of where I'd really like postgres to replace sqlite: https://github.com/pedrocr/syncer/ https://github.com/pedrocr/syncer/ I've had to add an extra caching layer because of sqlite INSERT performance. Given that I've already had to code around limitations and the schema is simple I will probably end up using a simpler non-SQL database in the future instead.
- hizanberg 7y ago
  > There's nothing about being embeddable that's a limitation. An always-running in-memory server process is going to be a lot better at concurrency than multiple embeddable libraries trying to take locks out on the same file on disk.
  - pedrocr 7y ago
    Read what I wrote. What I want is always-running in-memory. Being embeddable doesn't mean you need to have the sqlite model where several processes access the same database. None of the sqlite uses I've had required that at all.