9 ms·

SparkFun's migration from MariaDB to PostgreSQL

rpedela 13y ago
So why did you migrate? There is a very brief mention of needing to scale an order of magnitude or two. Could you elaborate?
- deleted 13y ago
  [deleted]
- thepicard 13y ago
  I also have this question. There are technical reasons that PostgreSQL is better than MySQL, especially when it comes to features, but none are mentioned here. > From the development perspective Postgres was a necessity. Not a slam dunk but objectively a better tool for our use case. In what way? > And if we have countless reasons, all good, but they’re nuanced and technical and tricky to impart to a non-technical audience, where does that leave us? HN would be interested in those reasons, I know I am. > The vast majority of the company probably still doesn’t get why we went through this painful contortion at the expense of doing, well, a lot of other things. Neither do I, since none are given. Though I also understand that the point of the post was about trust. It's great that there is that trust within SparkFun, I would love such an environment.
- brennen 13y ago
  Awright, so I didn't write the linked piece, but Chris isn't talking about scaling our web traffic by an order of magnitude. We're a small-to-mid-size web store & light manufacturer and we do decent business and very occasionally get a bunch of traffic as far as mid-sized web stores go. We're not a big service provider, and we're never going to be one in the sense where we have to worry about scale the way that people with Real Problems do. We do plan to store a bunch more data than we deal with now, but mostly we migrated because we're looking to build a better ball of mud, to borrow a perfectly legitimate analogy from elsewhere in the thread. What we'd like to scale somewhat cleanly is a business which benefits from us building less broken applications, and PostgreSQL is obviously a less broken foundation for the kind of software where it matters if you are correct about things. If anyone would like a reason to let us know at length what incomparable buffoons we must be for any of writing PHP, rolling our own application framework, still owning physical hardware, or getting a little overexcited when the code doesn't break too badly, I will cop to all of those and more in public, but please don't read the linked post as a strong technical claim about Hard Problems in the Land of Webscalonia which demands & merits a detailed refutation. Posts on sparkfun.com don't tend to be written for a web nerd audience (we sell blinkenlights) and most of us survey a very different conceptual landscape on a day-to-day basis from the average HN reader. (For clarity here, I write web stuff at SparkFun, and most of my time lately has been on this project. Author of linked piece is my boss.) Edit: And my apologies if this reply to a rather simple question comes off a bit reactive; consider this my reply to the thread as a whole?
  - strlen 13y ago
    Not reactive at all, well put response to mostly confused posts (including my own). I think there was mis-understanding on what was meant by scaling -- web community took it to mean something very different from what you meant. Honestly this befuddled me as well me as well, so I suspected as much -- I didn't think Sparkfun would need to go to horizontal scaling which I am quite confident you'll likely never need (unless you're doing something very wrong). One way someone else put it, MySQL is great if you're using it as a datastore to build an API layer on top (with relational features being a huge plus as opposed to a K/V store). Postgres, on the other hand, effectively does what an RDBMS was originally meant to do -- it itself acts as that data access API. Also SparkFun is an awesome company -- the SparkFun Arduino kits on my desk do a lot more than blink lights (though they do that too). Please continue to use run-times may be less trendy but which return responses quickly and using physical hardware too.
  - falcolas 13y ago
    Wait... > PostgreSQL is obviously a less broken foundation for the kind of software where it matters if you are correct about things. and > writing PHP, rolling our own application framework In the same explanation? Seems like you still have some points where you can make serious gains in your technology stack that would have bought you more tangible benefits albeit not as much positive publicity.
    - brennen 13y ago
      Thanks. I never know I'm actually in a conversation about how I do my job until this comment shows up.
      - falcolas 13y ago
        In my honest opinion, if you choose to change to PostgreSQL because it's "less broken" but still use PHP as your front end, I feel completely justified in asking WTF. Sure, you're securing the barn doors nicely, but the rest of the barn might as well be made of tissue paper. It is your job, and it's not my place to comment about how to do your job; but when making such a public announcement, 'less broken' when wrapped with PHP and custom frameworks isn't a very compelling message.
duncan_bayne 13y ago
One thing stood out for me in the article: "As mentioned here before, SparkFun.com is really the tip of a much bigger iceberg called Sparkle. Sparkle is an internal website where we hang every tool we need. It does everything but the core accounting." If you can share, what's the reason you folks went with this architecture? Beyond DB choices, I'd be very concerned about a design that tied so many important business functions into the one tech. stack, let alone the same application. I'd like to be able to do things like bring internal tools down for maintenance without hosing the public-facing CMS. Or change database technologies to suit whichever particular application I was optimising.
- gnaritas 13y ago
  The big ball of mud architecture is quite popular in the business world.
  - Glyptodon 13y ago
    When you have limited developer resources modular balls of mud (AKA big glob of Buckyballs - like the magnetic desk toy) with single login identity and shared well structured DB are far better and easier to maintain than a half dozen+ separate applications with differing architectural choices, languages, and abilities to integrate with each other. You do not know hell if you've never encountered a medium sized organization without much in house tech talent who've somehow ended up with 5 different application with database contents and business functionality overlap and completely different architectures and languages with no ability to integrate with each other. This is actually also the main reason I've come to dislike Rails - for complex businesses with single small teams or single developers it's hard to encapsulate different site functionalities as modular components of a larger system (more like 'apps' in Django) as compared to running multiple rails sites. This same need is also why many business (prepare to shoot yourself) try to do everything with Drupal. The ability to meet a need quickly with something that can just plug in easily to an existing system far outweighs anything else in most non-giant non-massive-scale organizations. This is part of why Rails is so successful despite not making it easy to modularize your site functionality - the components and libraries of the application overall are highly modular and community package resources make it so stuff can be built quickly even it's hard to modularize within the Rails application itself. The big bad ball of mud is more an outgrowth of business trying to move quickly and demanding their flavor of the week without being able to understand, plan, or manage the quality of their developers, modularity of their code, or the development process, rather than complex single (but modular) systems being bad.
strlen 13y ago
Not to bikeshed, but what about Postgres makes the big scalability story any different than the MySQL story, unless you're talking about a commercial distributed RDBMS built on top of Postgres like EnterpriseDB? In terms of scalability in the small, many of the MySQL 5.6 replication features skew this comparison in MySQL's direction: multi-threaded (optionally row-based) replication, global transaction ids, and the like make it easier to improve availability, add read-slaves, and host multiple databases/shards on a single machine (replication afaik is no longer per-server, it is now per-database). There's also been work on tuning innodb for SSDs (which is a near certain recommendation for your dataset -- it gives plenty of breathing room to forestall horizontal partitioning). I'd also look very heavily into performance with large buffer caches, compression (great way to reduce IOPS and squeeze the most out of SSD or memory space), etc... I am curious to see if any of these were compared between MySQL and Postgres. As far as I understand, innodb's compression is somewhat more advanced than Postgres, but running either on ZFS is an even better bet for this. On the other hand, Postgres has a better query optimizer, supports more complex data and relation formats, and so on. However, most of these features aren't going to be used at scale (I am presuming you're talking about OLTP workloads). Honestly this is a bit of an unusual decision -- I'd probably start a project with Postgres and avoid using MySQL until later, but choosing Postgres out of scalability reasons seems a bit odd. I'm curious to know why!
- gbog 13y ago
  Maybe it was not only for scalability, but also for reliability or embracing the Do the Right Thing thing? From my experience with PostgreSQL and MySQL, it is a bit like the difference between python and php, one is a great work of craftmanship that is reliable, predictible, coherent, enjoyable to work with and minimise the wtf/mn rate (which is the best quality measure in software), while the other is a bunch of hacks knit together to make it work asap and its wtf/mn is skyscraping.
  - strlen 13y ago
    Those are perfectly fine reasons, but the stated reason had been scalability.
jeffdavis 13y ago
I don't like the "right tool for the job" analogy. When you use a hammer to put in a nail, the hammer isn't a part of the building when you're done with it. But when you choose a DBMS, you're stuck with it in your architecture for a long time and it's a huge cost to migrate. (I'm a postgres community member, so of course I'm glad it's working out for them, but I just don't like the analogy.)
- Snowda 13y ago
  I think its less hammer more nail vs screw. Both can hold wood to a wall and will be part of the building when you are done. For example a nail can splinter the wood which can cause a break down the line while a screw wouldn't encounter such an issue.
  - girvo 13y ago
    That goes even further, a nail gun can be much faster than a drill when doing large construction, but is more dangerous and easier to hurt yourself or mess up with. Ie. MySQL is easier to get started with (well, was, nowadays it's much of a muchness), and is easier to scale in some situations but you trade for some other features and useful things. Screws and nails are both useful, but I wouldn't just rely on one for every project :)
lstamour 13y ago
It sounds like they really wanted PostGIS. Though they never mentioned it. Or how MySQL has spatial extensions. Really, I'm at a bit of a loss as to why they switched, but congrats and good luck. Glad to see another MariaDB mention. Just found Galera myself. Wish WordPress supported Postgres.
- skyebook 13y ago
  I was thinking the same thing about wanting to go PostGIS. Though they could probably do just as well for their needs (presuming the case is in a single building) by using vanilla postgres' geometric functions. Kind of a moot point since they were using MariaDB anyway, but the MySQL geospatial functionality hasn't gotten much attention in a long time. I remember quite distinctly hearing at the MySQL BoF at OSCON 2011 that the original author of the MySQL geospatial stuff was gone from Oracle. I find it hard to believe that they haven't picked up anyone to continue development on that but when you compare features with PostGIS, there's almost no point in even trying to compete. /geo-rant
  - conradfr 13y ago
    In fact it got new features in MySql 5.6.
    - skyebook 13y ago
      Cool, I'll have to check it out.. thanks!
- Frencil 13y ago
  I presume you're recommending PostGIS because of the allusions to the inventory location problem. While better modelling of geo data would be nice it's kind of a different concern. For us inventory location isn't about where on Earth our inventory is, or even where geometrically it is relative to something else, it's about where in a hierarchy of named locations it is. For instance: we have 10 of widget X in the storefront stock room, row F, rack 17, shelf 3, bin 1. Or we have 22 of widget Y in the receiving room on the quarantine table. Stuff like that. When modelling that many semantic nested locations and all of the transfers of items between them the primary issue is scalability and speed, not so much modelling geographic data.
mkesper 13y ago
As a sidequestion, what's a good ressource for getting into the postgres world?
- adamzegelin 13y ago
  The PostgreSQL documentation. http://www.postgresql.org/docs/9.3/static/index.html http://www.postgresql.org/docs/9.3/static/index.html The introduction tutorial is concise but more than sufficient. The reference guide is well written, laid-out and covers everything you need: the database server, its configuration and tools, the SQL language, its operators, data types and grammar, the built-in procedural languages, the low-level client library, and all the database internals (system tables, data file formats, network protocol, query optimiser, indexes, etc).
  - brennen 13y ago
    I'd second this. I've pretty much fallen in love with the official docs over the last few months. They remind me of perldoc in terms of clarity and general quality. The mailing lists also seem to carry a lot of good material.
gnur 13y ago
As a hobby-projects-only developer, would there be any reason to switch from mariaBD to postgreSQL? Scalability is no issue for me (I don't have to scale). And lately I hardly write any queries myself because of django..
- andybak 13y ago
  Yep. South is much happier with postgrSQL as it can do schema changes in a transaction and roll them back if there's a problem. MySQL will just leave you with a half completed schema change which you'll have to fix by hand.
  - gnur 13y ago
    Ah good to know, doing my research also tells me Django 1.7 will include migrations out of the box with schema change transactions as well. Thanks!
- raverbashing 13y ago
  For your case, especially using the Django ORM, no reason whatsoever. Or, ok, there may be a reason, South used to not play so well with MySQL/MariaDB, this has improved over time but still may be a reason to use PostgreSQL (Or just don't bother and use SQLite, depending on your case it may be just fine)
  - collyw 13y ago
    South still regularly complains at me for not using Postgress.
    - raverbashing 13y ago
      Yes, it complains, still, I'm not sure how much is truly "PostgreSQL is better" and how much is South not caring/not working around some issues. Or even how much is limitations on the Python or Django DB drivers (two separate things)
- DrJokepu 13y ago
icebraining 13y ago
I have to wonder why are they trying to build an homegrown ERP system. Inventory location is a solved problem, readily available as Free Software.
- Frencil 13y ago
  Inventory location is one of many, many problems our ERP system is tasked with. And we've looked at a lot of software packages over the years, both proprietary and open. In terms of open software the options are actually pretty limited and have the potential to introduce more problems with integration and customization than they would purport to solve by bringing in new suites of features. What is less limited and truly abundant are examples of other companies in our same position that went full-bore into an off-the-shelf solution and ended up severely disrupting their business operations and aborting transitions.
  - icebraining 13y ago
    Well, I'm biased since I'm paid to build those systems (we are OpenERP partners), but if it works for you, I won't argue ;)
    - brennen 13y ago
      If nothing else, it's probably time we give OpenERP another look just to get an idea of how problems are being handled there. Pointers to useful reading would be welcome, if you've got any.
      - icebraining 13y ago
        The best introduction is probably Integrate You Logistic Processes with OpenERP, a free ebook written by OpenERP S.A. themselves[1]. It's slightly outdated, since it was published in 2011 and meanwhile version 7.0 has been released, but the changes to the stock area where limited (except for the UI). We have a demo instance for version 7.0 [2], but it's in Portuguese (though you can change the language). OpenERP S.A. offers a free trial. [1] http://www.brain-tec.ch/ebusiness-de-2/openERP/logistic-prozesses.pdf http://www.brain-tec.ch/ebusiness-de-2/openERP/logistic-proz... [2] https://demo7.thinkopensolutions.com/?db=demo&user=demo&password=demo https://demo7.thinkopensolutions.com/?db=demo&user=demo&pass...
Mister_Snuggles 13y ago
One of the links in this article goes into a little more detail of why they switched: https://www.sparkfun.com/news/1239 https://www.sparkfun.com/news/1239 > See, MySQL and its forks, for all of the really huge > and amazing stuff built on them in the last decade, > have got some drawbacks. On this point, I risk triggering > a lot of strong feelings from the sort of people who > have strong feelings about databases, so for the time > being, let's just say that it started to seem like we'd > have a better time writing business software on a > database that embodied a more rigorous approach to > formal types and relationships. And because of years > of our nerd friends telling us we should probably just > use PostgreSQL, it kind of seemed like PostgreSQL might > be that database, especially since we already knew we > were going to use something with open code. The phrase "...we'd have a better time writing business software on a database that embodied a more rigorous approach to formal types and relationships." is what nails it for me. This isn't a technical feature, per se, of PostgreSQL, it's more of an attitude that's embodied in the product.

So why did you migrate? There is a very brief mention of needing to scale an order of magnitude or two. Could you elaborate?

deleted 13y ago
[deleted]
thepicard 13y ago
I also have this question. There are technical reasons that PostgreSQL is better than MySQL, especially when it comes to features, but none are mentioned here. > From the development perspective Postgres was a necessity. Not a slam dunk but objectively a better tool for our use case. In what way? > And if we have countless reasons, all good, but they’re nuanced and technical and tricky to impart to a non-technical audience, where does that leave us? HN would be interested in those reasons, I know I am. > The vast majority of the company probably still doesn’t get why we went through this painful contortion at the expense of doing, well, a lot of other things. Neither do I, since none are given. Though I also understand that the point of the post was about trust. It's great that there is that trust within SparkFun, I would love such an environment.
brennen 13y ago
Awright, so I didn't write the linked piece, but Chris isn't talking about scaling our web traffic by an order of magnitude. We're a small-to-mid-size web store & light manufacturer and we do decent business and very occasionally get a bunch of traffic as far as mid-sized web stores go. We're not a big service provider, and we're never going to be one in the sense where we have to worry about scale the way that people with Real Problems do. We do plan to store a bunch more data than we deal with now, but mostly we migrated because we're looking to build a better ball of mud, to borrow a perfectly legitimate analogy from elsewhere in the thread. What we'd like to scale somewhat cleanly is a business which benefits from us building less broken applications, and PostgreSQL is obviously a less broken foundation for the kind of software where it matters if you are correct about things. If anyone would like a reason to let us know at length what incomparable buffoons we must be for any of writing PHP, rolling our own application framework, still owning physical hardware, or getting a little overexcited when the code doesn't break too badly, I will cop to all of those and more in public, but please don't read the linked post as a strong technical claim about Hard Problems in the Land of Webscalonia which demands & merits a detailed refutation. Posts on sparkfun.com don't tend to be written for a web nerd audience (we sell blinkenlights) and most of us survey a very different conceptual landscape on a day-to-day basis from the average HN reader. (For clarity here, I write web stuff at SparkFun, and most of my time lately has been on this project. Author of linked piece is my boss.) Edit: And my apologies if this reply to a rather simple question comes off a bit reactive; consider this my reply to the thread as a whole?
- strlen 13y ago
  Not reactive at all, well put response to mostly confused posts (including my own). I think there was mis-understanding on what was meant by scaling -- web community took it to mean something very different from what you meant. Honestly this befuddled me as well me as well, so I suspected as much -- I didn't think Sparkfun would need to go to horizontal scaling which I am quite confident you'll likely never need (unless you're doing something very wrong). One way someone else put it, MySQL is great if you're using it as a datastore to build an API layer on top (with relational features being a huge plus as opposed to a K/V store). Postgres, on the other hand, effectively does what an RDBMS was originally meant to do -- it itself acts as that data access API. Also SparkFun is an awesome company -- the SparkFun Arduino kits on my desk do a lot more than blink lights (though they do that too). Please continue to use run-times may be less trendy but which return responses quickly and using physical hardware too.
- falcolas 13y ago
  Wait... > PostgreSQL is obviously a less broken foundation for the kind of software where it matters if you are correct about things. and > writing PHP, rolling our own application framework In the same explanation? Seems like you still have some points where you can make serious gains in your technology stack that would have bought you more tangible benefits albeit not as much positive publicity.
  - brennen 13y ago
    Thanks. I never know I'm actually in a conversation about how I do my job until this comment shows up.
    - falcolas 13y ago
      In my honest opinion, if you choose to change to PostgreSQL because it's "less broken" but still use PHP as your front end, I feel completely justified in asking WTF. Sure, you're securing the barn doors nicely, but the rest of the barn might as well be made of tissue paper. It is your job, and it's not my place to comment about how to do your job; but when making such a public announcement, 'less broken' when wrapped with PHP and custom frameworks isn't a very compelling message.

duncan_bayne 13y ago

One thing stood out for me in the article: "As mentioned here before, SparkFun.com is really the tip of a much bigger iceberg called Sparkle. Sparkle is an internal website where we hang every tool we need. It does everything but the core accounting." If you can share, what's the reason you folks went with this architecture? Beyond DB choices, I'd be very concerned about a design that tied so many important business functions into the one tech. stack, let alone the same application. I'd like to be able to do things like bring internal tools down for maintenance without hosing the public-facing CMS. Or change database technologies to suit whichever particular application I was optimising.

gnaritas 13y ago
The big ball of mud architecture is quite popular in the business world.
- Glyptodon 13y ago
  When you have limited developer resources modular balls of mud (AKA big glob of Buckyballs - like the magnetic desk toy) with single login identity and shared well structured DB are far better and easier to maintain than a half dozen+ separate applications with differing architectural choices, languages, and abilities to integrate with each other. You do not know hell if you've never encountered a medium sized organization without much in house tech talent who've somehow ended up with 5 different application with database contents and business functionality overlap and completely different architectures and languages with no ability to integrate with each other. This is actually also the main reason I've come to dislike Rails - for complex businesses with single small teams or single developers it's hard to encapsulate different site functionalities as modular components of a larger system (more like 'apps' in Django) as compared to running multiple rails sites. This same need is also why many business (prepare to shoot yourself) try to do everything with Drupal. The ability to meet a need quickly with something that can just plug in easily to an existing system far outweighs anything else in most non-giant non-massive-scale organizations. This is part of why Rails is so successful despite not making it easy to modularize your site functionality - the components and libraries of the application overall are highly modular and community package resources make it so stuff can be built quickly even it's hard to modularize within the Rails application itself. The big bad ball of mud is more an outgrowth of business trying to move quickly and demanding their flavor of the week without being able to understand, plan, or manage the quality of their developers, modularity of their code, or the development process, rather than complex single (but modular) systems being bad.

strlen 13y ago

Not to bikeshed, but what about Postgres makes the big scalability story any different than the MySQL story, unless you're talking about a commercial distributed RDBMS built on top of Postgres like EnterpriseDB? In terms of scalability in the small, many of the MySQL 5.6 replication features skew this comparison in MySQL's direction: multi-threaded (optionally row-based) replication, global transaction ids, and the like make it easier to improve availability, add read-slaves, and host multiple databases/shards on a single machine (replication afaik is no longer per-server, it is now per-database). There's also been work on tuning innodb for SSDs (which is a near certain recommendation for your dataset -- it gives plenty of breathing room to forestall horizontal partitioning). I'd also look very heavily into performance with large buffer caches, compression (great way to reduce IOPS and squeeze the most out of SSD or memory space), etc... I am curious to see if any of these were compared between MySQL and Postgres. As far as I understand, innodb's compression is somewhat more advanced than Postgres, but running either on ZFS is an even better bet for this. On the other hand, Postgres has a better query optimizer, supports more complex data and relation formats, and so on. However, most of these features aren't going to be used at scale (I am presuming you're talking about OLTP workloads). Honestly this is a bit of an unusual decision -- I'd probably start a project with Postgres and avoid using MySQL until later, but choosing Postgres out of scalability reasons seems a bit odd. I'm curious to know why!

gbog 13y ago
Maybe it was not only for scalability, but also for reliability or embracing the Do the Right Thing thing? From my experience with PostgreSQL and MySQL, it is a bit like the difference between python and php, one is a great work of craftmanship that is reliable, predictible, coherent, enjoyable to work with and minimise the wtf/mn rate (which is the best quality measure in software), while the other is a bunch of hacks knit together to make it work asap and its wtf/mn is skyscraping.
- strlen 13y ago
  Those are perfectly fine reasons, but the stated reason had been scalability.

jeffdavis 13y ago

I don't like the "right tool for the job" analogy. When you use a hammer to put in a nail, the hammer isn't a part of the building when you're done with it. But when you choose a DBMS, you're stuck with it in your architecture for a long time and it's a huge cost to migrate. (I'm a postgres community member, so of course I'm glad it's working out for them, but I just don't like the analogy.)

Snowda 13y ago
I think its less hammer more nail vs screw. Both can hold wood to a wall and will be part of the building when you are done. For example a nail can splinter the wood which can cause a break down the line while a screw wouldn't encounter such an issue.
- girvo 13y ago
  That goes even further, a nail gun can be much faster than a drill when doing large construction, but is more dangerous and easier to hurt yourself or mess up with. Ie. MySQL is easier to get started with (well, was, nowadays it's much of a muchness), and is easier to scale in some situations but you trade for some other features and useful things. Screws and nails are both useful, but I wouldn't just rely on one for every project :)

lstamour 13y ago

It sounds like they really wanted PostGIS. Though they never mentioned it. Or how MySQL has spatial extensions. Really, I'm at a bit of a loss as to why they switched, but congrats and good luck. Glad to see another MariaDB mention. Just found Galera myself. Wish WordPress supported Postgres.

skyebook 13y ago
I was thinking the same thing about wanting to go PostGIS. Though they could probably do just as well for their needs (presuming the case is in a single building) by using vanilla postgres' geometric functions. Kind of a moot point since they were using MariaDB anyway, but the MySQL geospatial functionality hasn't gotten much attention in a long time. I remember quite distinctly hearing at the MySQL BoF at OSCON 2011 that the original author of the MySQL geospatial stuff was gone from Oracle. I find it hard to believe that they haven't picked up anyone to continue development on that but when you compare features with PostGIS, there's almost no point in even trying to compete. /geo-rant
- conradfr 13y ago
  In fact it got new features in MySql 5.6.
  - skyebook 13y ago
    Cool, I'll have to check it out.. thanks!
Frencil 13y ago
I presume you're recommending PostGIS because of the allusions to the inventory location problem. While better modelling of geo data would be nice it's kind of a different concern. For us inventory location isn't about where on Earth our inventory is, or even where geometrically it is relative to something else, it's about where in a hierarchy of named locations it is. For instance: we have 10 of widget X in the storefront stock room, row F, rack 17, shelf 3, bin 1. Or we have 22 of widget Y in the receiving room on the quarantine table. Stuff like that. When modelling that many semantic nested locations and all of the transfers of items between them the primary issue is scalability and speed, not so much modelling geographic data.

mkesper 13y ago

As a sidequestion, what's a good ressource for getting into the postgres world?

adamzegelin 13y ago
The PostgreSQL documentation. http://www.postgresql.org/docs/9.3/static/index.html http://www.postgresql.org/docs/9.3/static/index.html The introduction tutorial is concise but more than sufficient. The reference guide is well written, laid-out and covers everything you need: the database server, its configuration and tools, the SQL language, its operators, data types and grammar, the built-in procedural languages, the low-level client library, and all the database internals (system tables, data file formats, network protocol, query optimiser, indexes, etc).
- brennen 13y ago
  I'd second this. I've pretty much fallen in love with the official docs over the last few months. They remind me of perldoc in terms of clarity and general quality. The mailing lists also seem to carry a lot of good material.

gnur 13y ago

As a hobby-projects-only developer, would there be any reason to switch from mariaBD to postgreSQL? Scalability is no issue for me (I don't have to scale). And lately I hardly write any queries myself because of django..

andybak 13y ago
Yep. South is much happier with postgrSQL as it can do schema changes in a transaction and roll them back if there's a problem. MySQL will just leave you with a half completed schema change which you'll have to fix by hand.
- gnur 13y ago
  Ah good to know, doing my research also tells me Django 1.7 will include migrations out of the box with schema change transactions as well. Thanks!
raverbashing 13y ago
For your case, especially using the Django ORM, no reason whatsoever. Or, ok, there may be a reason, South used to not play so well with MySQL/MariaDB, this has improved over time but still may be a reason to use PostgreSQL (Or just don't bother and use SQLite, depending on your case it may be just fine)
- collyw 13y ago
  South still regularly complains at me for not using Postgress.
  - raverbashing 13y ago
    Yes, it complains, still, I'm not sure how much is truly "PostgreSQL is better" and how much is South not caring/not working around some issues. Or even how much is limitations on the Python or Django DB drivers (two separate things)
DrJokepu 13y ago

icebraining 13y ago

I have to wonder why are they trying to build an homegrown ERP system. Inventory location is a solved problem, readily available as Free Software.

Frencil 13y ago
Inventory location is one of many, many problems our ERP system is tasked with. And we've looked at a lot of software packages over the years, both proprietary and open. In terms of open software the options are actually pretty limited and have the potential to introduce more problems with integration and customization than they would purport to solve by bringing in new suites of features. What is less limited and truly abundant are examples of other companies in our same position that went full-bore into an off-the-shelf solution and ended up severely disrupting their business operations and aborting transitions.
- icebraining 13y ago
  Well, I'm biased since I'm paid to build those systems (we are OpenERP partners), but if it works for you, I won't argue ;)
  - brennen 13y ago
    If nothing else, it's probably time we give OpenERP another look just to get an idea of how problems are being handled there. Pointers to useful reading would be welcome, if you've got any.
    - icebraining 13y ago
      The best introduction is probably Integrate You Logistic Processes with OpenERP, a free ebook written by OpenERP S.A. themselves[1]. It's slightly outdated, since it was published in 2011 and meanwhile version 7.0 has been released, but the changes to the stock area where limited (except for the UI). We have a demo instance for version 7.0 [2], but it's in Portuguese (though you can change the language). OpenERP S.A. offers a free trial. [1] http://www.brain-tec.ch/ebusiness-de-2/openERP/logistic-prozesses.pdf http://www.brain-tec.ch/ebusiness-de-2/openERP/logistic-proz... [2] https://demo7.thinkopensolutions.com/?db=demo&user=demo&password=demo https://demo7.thinkopensolutions.com/?db=demo&user=demo&pass...

Mister_Snuggles 13y ago

One of the links in this article goes into a little more detail of why they switched: https://www.sparkfun.com/news/1239 https://www.sparkfun.com/news/1239 > See, MySQL and its forks, for all of the really huge > and amazing stuff built on them in the last decade, > have got some drawbacks. On this point, I risk triggering > a lot of strong feelings from the sort of people who > have strong feelings about databases, so for the time > being, let's just say that it started to seem like we'd > have a better time writing business software on a > database that embodied a more rigorous approach to > formal types and relationships. And because of years > of our nerd friends telling us we should probably just > use PostgreSQL, it kind of seemed like PostgreSQL might > be that database, especially since we already knew we > were going to use something with open code. The phrase "...we'd have a better time writing business software on a database that embodied a more rigorous approach to formal types and relationships." is what nails it for me. This isn't a technical feature, per se, of PostgreSQL, it's more of an attitude that's embodied in the product.