Migrating Graphite from SQLite to PostgreSQL
obfuscurity.com
Migrating Graphite from SQLite to PostgreSQL
1–10 of 21 posts
Re: Migrating Graphite from SQLite to PostgreSQL
#2As a fan of both databases, I just have to say, you don't always need all the constraints.
Also, at the very least, graphite should have been able to enforce them at the app level in addition to at the DB level.
Re: Migrating Graphite from SQLite to PostgreSQL
#3As a fan of both databases, I just have to say, you don't always need all the constraints. Also, at the very least, graphite should have been able to enforce them at the app level in addition to at the DB level.
I completely agree. I was rather disappointed to find that it didn't.
Re: Migrating Graphite from SQLite to PostgreSQL
#4There 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.
Re: Migrating Graphite from SQLite to PostgreSQL
#5There 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 is no reason why one would use SQLite in real production.
Yes there is. Small storage for a local app? SQLite is ideal.
Re: Migrating Graphite from SQLite to PostgreSQL
#6There 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 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.
Re: Migrating Graphite from SQLite to PostgreSQL
#7There 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.
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 know now, I would've never done that. ;-)
Re: Migrating Graphite from SQLite to PostgreSQL
#8There 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.
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 use SQLite for heavy loading application such as logging. And I think we can now agree that's indeed true and I think we should promote people to use production-ready DBMS even during dev and testing, because those are the one you are going to use in production :)
Re: Migrating Graphite from SQLite to PostgreSQL
#9As a fan of both databases, I just have to say, you don't always need all the constraints. Also, at the very least, graphite should have been able to enforce them at the app level in addition to at the DB level.
I completely agree. I was rather disappointed to find that it didn't.
Is it by default it ships with SQLite or just Doc?
Re: Migrating Graphite from SQLite to PostgreSQL
#10Earlier 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…
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 from apt-get and then forgetting about it.