Earlier quoted context omitted.
I completely agree. I was rather disappointed to find that it didn't.
Is it by default it ships with SQLite or just Doc?
I'm not sure what you're asking here. Graphite uses SQLite by default. What is "Doc"?
Migrating Graphite from SQLite to PostgreSQL
11–20 of 21 posts
Re: Migrating Graphite from SQLite to PostgreSQL
#12Earlier quoted context omitted.
I disagree because it is internal facing lol. If the software is capable of running on a true production-ready DBMS, there is no point why it can't be done already. If SQLite is cheap to use because it's a single file, well, a sudo apt-get install PostgreSQL and then a few commands to set up the database and user password won't take you longer than 10 minutes. That's what I am arguing. There is no reason why we would…
Nobody ever said it /can't/ be done. I would never have argued against using a real RDBMS. But I've often been guilty of telling folks that SQLite was "good enough". Installing PostgreSQL as you described is not "good enough". If you're going to bother with that, you need to understand the database enough to tune it properly, setup backups, test restores, etc. There are more considerations than simply installing it f…
Yes that's true, but by default they come with good configurations which should enable better write and read in most cases against SQLite :)
Re: Migrating Graphite from SQLite to PostgreSQL
#13Re: Migrating Graphite from SQLite to PostgreSQL
#14Earlier quoted context omitted.
I completely agree. I was rather disappointed to find that it didn't.
Is it by default it ships with SQLite or just Doc?
It is configured to use SQLite by default, but it doesn't ship /embed/vendorize it. You're required to install the sqlite bindings yourself.
Re: Migrating Graphite from SQLite to PostgreSQL
#15There is no reason why one would use SQLite in real production. Even during testing and dev, I am a firm believer of testing against real database that you are going to use in production. The problem "it's hard to setup a new database" is a result of not willing to invest in re-provisionable system.
There are plenty of reasons.
* Single file to back up
* Unix fs permissions sufficient for security
* Simplicity valuable over write concurrency
* Ability to write functions/aggregates/collations in the language you're embedding sqlite in
* No need for maintaining and securing a system daemon
TL;DR - graphite devs don't understand postgresql, graphite user misdiagnoses the problem and blames sqlite for it.
Re: Migrating Graphite from SQLite to PostgreSQL
#16Earlier quoted context omitted.
There is no reason why one would use SQLite in real production. Yes there is. Small storage for a local app? SQLite is ideal.
We are not on the same page. I was referring to Graphite and general web application. We are talking about real server serving pages to users. Localstorage and app in desktop and mobile are definitely arguable.
Having used CoreData/Sqlite on iOS I yearn for Postgres.
Re: Migrating Graphite from SQLite to PostgreSQL
#17Meh, SQLite is awesome. So is PostgreSQL, but this rant is uncalled for.
Re: Migrating Graphite from SQLite to PostgreSQL
#18Earlier quoted context omitted.
Except that while Graphite is a "real web application", it's generally internal-facing only. As such, I never looked at it as needing a true "production-ready" RDBMS with real concurrency. And to be honest, we got by just fine with it in production at Heroku and GitHub, at heavy volume, running in a single server on SQLite. It never bit us, and all things considered, was a reasonable choice. That said, knowing what I…
I disagree because it is internal facing lol. If the software is capable of running on a true production-ready DBMS, there is no point why it can't be done already. If SQLite is cheap to use because it's a single file, well, a sudo apt-get install PostgreSQL and then a few commands to set up the database and user password won't take you longer than 10 minutes. That's what I am arguing. There is no reason why we would…
[deleted]
Re: Migrating Graphite from SQLite to PostgreSQL
#19There is no reason why one would use SQLite in real production. Even during testing and dev, I am a firm believer of testing against real database that you are going to use in production. The problem "it's hard to setup a new database" is a result of not willing to invest in re-provisionable system.
There are plenty of reasons. * Single file to back up * Unix fs permissions sufficient for security * Simplicity valuable over write concurrency * Ability to write functions/aggregates/collations in the language you're embedding sqlite in * No need for maintaining and securing a system daemon This article isn't, at all, about a problem with SQLite. It's about graphite shipping a stupid postgres schema. Had they used…
The way I read this, this _is_ a problem with SQLite (somewhat). Both schemas limit the length of graph names, but SQLite ignores that part of the schema.
One can discuss whether it is a good idea to have that arbitrary, low limit, but that is not what this is about.
I agree that there are plenty of reasons to use SQLite in production. IMO, the conclusion should have been that one should run the same database in development, test, and production.
Re: Migrating Graphite from SQLite to PostgreSQL
#20There is no reason why one would use SQLite in real production. Even during testing and dev, I am a firm believer of testing against real database that you are going to use in production. The problem "it's hard to setup a new database" is a result of not willing to invest in re-provisionable system.
There are plenty of reasons. * Single file to back up * Unix fs permissions sufficient for security * Simplicity valuable over write concurrency * Ability to write functions/aggregates/collations in the language you're embedding sqlite in * No need for maintaining and securing a system daemon This article isn't, at all, about a problem with SQLite. It's about graphite shipping a stupid postgres schema. Had they used…
Excuse my french, but you're an idiot. I don't know if you simply didn't read the article, or are incapable of grasping the facts within.