As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I know that both these databases are better for different scenarios but in terms of a website where users will login and enter numerical data to a daily log, which one would it be best to use? I read that mySQL is faster to begin with but PostgreSQL is more scalable if the website were to start getting a lot of users?
The downside is that my host only offers mySQL and so to use postgreSQL I would have to purchase VPS hosting which is more expensive. I have also read people advising people to not worry about it to begin with, however it concerns me that I would have to rewrite queries and forms if I later moved to postgreSQL? I would appreciate everyone's thoughts on this.
I don't understand why people have given this question negative marks when I clearly stated that I am from a finance background and only started learning 3 weeks ago. I think you need to remember that everyone has to start somewhere and that we haven't all been doing this as a job/hobby for years. I would love to see some of you come out of your comfort zone and come and do my job for a day as you would be equally as clueless and I can guarantee that I would not be so rude as some of you have been here. You should be trying to create an environment of learning and innovation, rather than an environment of arrogance. If everyone knew everything, what would be the point in this website?
Disclaimer: I have worked a lot more with PostgreSQL than with MySQL
From a performance/scalability point of view both are probably pretty much the same. There are workloads where Postgres is better and there are workloads where MySQL is better. Unless you test it in your environment it's hard to tell which one would work better for you.
Postgres seems (seemed?) to be faster in a workload with a lot of concurrent writes, whereas MySQL seems to be better with heavy read-only workload. But those benchmarks are about 3-4 years old now, so they are probably no longer true - especially since InnoDB in MySQL 5.5 improved a lot in that area.
However PostgreSQL's SQL features are far more advanced than MySQL's and MySQL has a tendency to silently ignore things you tell it to do - especially in a default installation (and if you rely on a foreign key to be created that might be a very unpleasant surprise). MySQL still has an advantage in terms of clustering as far as I can tell.
They are both equal when it comes to High Availability solutions.
I strongly disagree with the opinion that one should avoid any DBMS specific features - utilizing all features of a DBMS will make your application more scalable and will increase performance.
Traditionally MySQL wasn't known for stability and quality of their releases, but that seems to have improved since Oracle has taken over.
I still don't like MySQL's release policy where they introduce major changes and features in minor releases. The PostgreSQL dev team has a much more strict policy about what goes into a minor release. Upgrading a minor release (i.e. bugfix releases) is much less "dangerous" in PostgreSQL than it is in MySQL.
Someone once said the big difference between the PG development and MySQL is: the Postgres team first makes sure your data is safe, then it makes sure everything is working correctly, then it makes it fast. Whereas the MySQL team first makes it fast, then correct and finally stable. But that too might have changed since the Oracle takeover.
Personally I'd always prefer PostgreSQL over MySQL because of the much better SQL feature set and the overall quality of the product.
MySQL is the more popular solution and is used by very large companies for very large databases, so MySQL is far from unscalable.
If you want the ability to move between both databases at a later date in case you decide to switch, I would recommend using an ORM (Look at http://www.doctrine-project.org/); this way you'll only have to write the queries once and if you change to a different database down the road, you only need to change a config variable. Doctrine will also have you build your database structure in a YAML file which it can convert for you as well.
It's also capable of migrating between database types.
You'll also want to take into account the different MySQL Engines which perform differently as well. I was just looking at a comparison between PostgreSQL and MySQL which in their conclusion, they didn't like the fact that MySQL wasn't built with transactions, however, InnoDB does provide transactional support for MySQL as well as speed and memory improvements in some cases.
So the bottom line is this: If you can make your application in such a way that you can use either database (as mentioned above) run your own benchmarks against your application and your databases and see what kind of a difference it makes to you.
There's certainly other things to think about if you have the budget for it and that's getting DBA's specific to the database you're using and get them to optimize it.
First, SQL is SQL, be sure that you use strict SQL, then you don't rewrite anything. The different between the both dbs is the level of SQL support. PosgreSQL has better support, but the support by MySQL depends on the used storage engine.
Yes, you can better scale your application with PostgeSQL, but how mach load have you on your server? 1GB per day, less more?
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I guess this has been brought up many times, but I'm bringing it up again!!!
Anyway... In Ruby on Rails Sqlite3 is already setup and no extra picking and slicing is needed, but...
after numerous readings here and other places, some say it's not scalable while others say it can actually be quite good at that. Some say MySQL is much better for bigger projects, while others think, just go with PostgreSQL.
I'm interested in hearing your opinion on this. In two scenarios. One where you are starting a little website for news publishing website like CNN news, and the other scenario where you're creating a website similar to Twitter?
Highly depends on your application.
Generally spoken, any write operation into a SQLite database is slow. Even a plain :update_attribute or :create may take up to 0.5 seconds. But if your App doesn't write much (killer against SQLite: write to DB on every request!), SQlite is a solid choice for most web apps out there. It is proven to handle small to medium amounts of traffic. Also, it is a very good choice during development, since it needs zero configuration. It performs also very well in your test suite with the in-memory mode (except you have thousands of migrations, since it rebuilds from scratch every time). Also, it is mostly seamless to switch from SQLite to, eg MySQL if its performance isn't enough any longer.
MySQL is currently a rock-solid choice. Future will tell what happens to MySQL under Oracle.
PostgreSQL is the fastest one as far as I know, but I haven't used it in production yet. Maybe others can tell more.
I'd vote for Postgres, it's consistently getting better, especially performance wise if that's a concern. Taking you up on the CNN and Twitter examples, start out with as solid footing as you can. You'll be glad later on down the road.
For websites, SQLite3 will suffice and scale fine for anything up to higher middle class traffic scenarios. So, unless you start getting hit by millions of requests per hour, there's no need to worry about SQLite3's performance or scalability.
That said, SQLite3 doesn't support all those typical features that a dedicated SQL server would. Access control is limited to whatever file permissions you can set for UNIX accounts on the machine with your database file, there's no daemon to speak of and the set of built-in functions is rather small. Also, there's no stored procedures of any kind, although you could emulate those with views and triggers.
If you're worried about any of those points, you should go with PostgreSQL. MySQL has (indirectly) been bought by Oracle, and considering they also had their own database before acquiring MySQL, I wouldn't put it past them to just drop it somewhere along the line. I've also had a far smoother experience maintaining PostgreSQL in the past and - anecdotally - it always felt a bit snappier and more reliable.
DISCLAIMER:
My opinion is completely bias as I have used mysql since it first came out.
Your question brings in another argument about how your development environment should be setup. A number of individuals will argue that you should be using the same dbms in development as you do in testing/production. This is totally dependent upon what you're doing in the first place. Sqlite will work fine, on development, in most cases.
I've personally been involved with more sites using MySql and MsSql than Postgres.
I was involved in a project that scrubbed the National Do-Not-Call list against client numbers. We stored that data locally. Some area codes easily have over 5 million records. The app was initially written in .Net using MsSql. It was "not-so-fast". I changed it to use PHP and MySql (Sad says before I found out about Ruby). It would insert/digest 5 million rows in(about) 3 seconds. Which was infinitely faster than processing it through MsSql. We also stored call log data in tables that would grow to 20 million records in less than a day. MySql handled everything we threw at it like a champ. The processing naturally took a hit when we setup replication but it was such a small one that we ignored it.
It really comes down to your project and what solution fits the need of the project.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Am not sure if this question makes sense. But I know all the basic CRUD commands of mysql. Probably a bit more here and there (foreign keys etc). But there are so many books written on mysql/dbms. I can write decent queries and get all my results as I want them. Maybe they aren't the most efficient but it worksforme. Thats because my apps arent facebook as yet that I have to worry about optimization. Or do I?
Am I missing the point here? What else should I know?
Thank you very much.
Premature optimization is the root of all evil. Focus on designing proper and logical database structures and indexing them correctly, that will take you far. Modifying a badly written query is always easier than modifying a badly designed database structure.
In my opinion, use the queries you have and optimize them when there is a need for optimization. What comes to the queries, rather focus on making them secure (see sql injection).
What else should I know?
Greater understanding of relational theory, so you write better SQL. I'm currently enjoying "SQL and Relational Theory," a new book by C. J. Date, the world's leading expert on the relational model.
Implementing and monitoring security - SQL injection certainly, but other issues covered by OWASP, SANS.org, or books like "19 Deadly Sins of Software Security." This is a broad topic not specific to SQL, but I think it's every software developer's duty to learn this stuff.
Performance measurement and monitoring - how will you know when you reach the point where you do need to learn optimization techniques?
I18N, L10N, character sets.
Database maintenance and recovery - backups, repair.
Replication, clustering, and proxying.
Deployment and upgrade techniques - how to apply changes to a running application or site without interrupting service.
Writing more-or-less portable SQL that works with multiple RDBMS brands. At least understand what needs to be rewritten if you need to support another brand.
How and when to employ Object-Relational Mapping frameworks.
How and when to employ non-relational databases. SQL is the best general-purpose data management paradigm, but there are other technologies more specialized to specific tasks.
Advanced MySQL is probably not just about writing queries for CRUD operations. Sometimes you need to do optimizations or various maintenance procedures that do require an intimate knowledge of the DBMS you are working with. You might not be worried about the performance of your queries and the robustness and efficiency of your database design if you deal with small to medium sized applications, but for a highly scalable application all these are factors that you have to take into account.
It's good to know CRUD syntax well. I would recommend that you go beyond that to understand relational design, primary and candidate keys, indexing, etc. These are topics that are meaningful for all relational databases, not just MySQL.
Databases are much more than just "Places to put stuff". Once you realize that, you will start using them to their full potential.
You should worry about optimization anyway imho. Sure if right now you have only 10 people who are using your application it's not the issue, but in the future if the user base grows it can really be a "pain in the ass" to rewrite database structure, especialy if in your code you are using the raw queries without database abstraction.
If you know enough to to do what needs to be done, then you know enough for now. However, Introduction to Database Systems by C.J. Date is an outstanding discussion of relational databases written by a pioneer in the field (as well as other types of database systems).
Generally, there are tons of features of mysql and other RDBMS systems that people aren't aware of. This is fine since you can get by well with a subset of features, but to deal with difficult problems or to be a good DBA there's a huge amount of stuff to learn. When people talk about Advanced X on databases, these are the types of things that are meant.
To answer your question, it's never a bad idea to find out what other features and tools are out there. You may find much better ways of solving your own problems and develop a better set of skills for solving other people's problems. I also fully agree with the other answers suggesting that you improve your knowledge on higher level topics, knowing how to make good db designs is extremely important.
Oh, now I get it (the question). I thought you meant "What is the point of combining 'Advanced' and 'MySQL'?". :-)
If you MUST use MySQL for your job, then yes, you had better gradually get a deeper understanding of it, especially what the shortcomings and gotchas are, and how other people at work may make assumptions about things that are not really going to work out.
Now, my "troll": if this is just you, use something a bit more robust. I'm no MicroSoft fan, but they do make the startup costs for using SQL Server pretty low, assuming you are working on Windows. Better yet, if you are working on a *nix server, you might try PostgreSQL. They have been pretty serious about correctly implementing quaint little things like ROLLBACK, transaction isolation, foreign key referential integrity, views, functions (aka stored procedures) for quite a few years. MySQL has improved over the years, but is still (IMHO) somewhat immature. My impression of it back around 2000 was "the reliability of xBASE with the ease of the SQL interface". (I'm not a big fan of the SQL language itself -- maybe I'm just too old to really warm up to it as the "the only possible way to do it")
I avoid MySQL like a bad flu bug, but I can add some insight here.
One area that would be covered in the "advanced" portion of MySQL is customization.
There is alot involved with SQL in general that MySQL doesn't do out of the box, or can be customized. Our company uses full stored procedure implementation and geospatial queries as two examples.
Advanced would involved good customization skills, and experience adding and working with customizations or add-ins. Anything to make MySQL be more enterprise like.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am working on a web application using Python (Django) and would like to know whether MySQL or PostgreSQL would be more suitable when deploying for production.
In one podcast Joel said that he had some problems with MySQL and the data wasn't consistent.
I would like to know whether someone had any such problems. Also when it comes to performance which can be easily tweaked?
A note to future readers: The text below was last edited in August 2008. That's nearly 11 years ago as of this edit. Software can change rapidly from version to version, so before you go choosing a DBMS based on the advice below, do some research to see if it's still accurate.
Check for newer answers below.
Better?
MySQL is much more commonly provided by web hosts.
PostgreSQL is a much more mature product.
There's this discussion addressing your "better" question
Apparently, according to this web page, MySQL is fast when concurrent access levels are low, and when there are many more reads than writes. On the other hand, it exhibits low scalability with increasing loads and write/read ratios. PostgreSQL is relatively slow at low concurrency levels, but scales well with increasing load levels, while providing enough isolation between concurrent accesses to avoid slowdowns at high write/read ratios. It goes on to link to a number of performance comparisons, because these things are very... sensitive to conditions.
So if your decision factor is, "which is faster?" Then the answer is "it depends. If it really matters, test your application against both." And if you really, really care, you get in two DBAs (one who specializes in each database) and get them to tune the crap out of the databases, and then choose. It's astonishing how expensive good DBAs are; and they are worth every cent.
When it matters.
Which it probably doesn't, so just pick whichever database you like the sound of and go with it; better performance can be bought with more RAM and CPU, and more appropriate database design, and clever stored procedure tricks and so on - and all of that is cheaper and easier for random-website-X than agonizing over which to pick, MySQL or PostgreSQL, and specialist tuning from expensive DBAs.
Joel also said in that podcast that comment would come back to bite him because people would be saying that MySQL was a piece of crap - Joel couldn't get a count of rows back. The plural of anecdote is not data. He said:
MySQL is the only database I've ever programmed against in my career that has had data integrity problems, where you do queries and you get nonsense answers back, that are incorrect.
and he also said:
It's just an anecdote. And that's one of the things that frustrates me, actually, about blogging or just the Internet in general. [...] There's just a weird tendency to make anecdotes into truths and I actually as a blogger I'm starting to feel a little bit guilty about this
Just chiming in many months later.
The geographical capabilities of the two databases are very, very different. PostgreSQL has the exceptional PostGIS extension. MySQL's geographical functionality is practically zero in comparison.
If your web service has a location component, choose PostgreSQL.
I haven't used Django, but I have used both MySQL and PostgreSQL. If you'll be using your database only as a backend for Django, it doesn't matter much, because it will abstract away most of the differences. PostgreSQL is a little more scalable because it doesn't hit the brick wall as fast as MySQL as data-size/client-count increase.
The real difference comes in if you are doing a new system. Then I'd recommend PostgreSQL hands down, because it has a lot more features which make your DB layer much more customizable, so that you can fine-tune it to any requirements you might have.
Although it's a bit out of date, it would be worth reading the MySQL Gotchas page. Many of the items listed there are still true, to the best of my knowledge.
I use PostgreSQL.
I use both extensively. My choice for a particular project boils down to:
Licensing - Are you going to distribute your app (IANAL)
Existing Infrastructure and Knowledge Base
Any special sauce you have to have.
By special sauce I mean things like:
Easy/cheap replication = MySQL
Huge dataset problems with small results = PostgreSQL. Use the language extensions, and have very efficient data operations. (PL/Python, PL/TCL, PL/Perl, etc)
Interface with R Statistical Libraries = PostgreSQL PL/R available in debian/ubuntu
Well, I don't think you should be using a different database brand in anything past development (build, staging, prod) as that will come back to bite you.
From how I understand it PostgreSQL is a more 'correct' database implementation while mySQl is less correct (less compliant) but faster.
So if you are pretty much writing a CRUD application mySQL is the way to go. If you require certain features out of your database (if you're not sure then you don't) then you may want to look into postgreSQL.
If you are writing an application which may get distributed quite a bit on different servers, MySQL carries a lot of weight over PostgreSQL because of the portability. PostgreSQL is difficult to find on less than satisfactory web hosts, albeit there are a few. In most regards, PostgreSQL is slower than MySQL, especially when it comes to fine tuning in the end. All in all, I'd say to give PostgreSQL a shot for a short amount of time, that way you aren't completely avoiding it, and then make a judgement.
Thank you. I've used Django with MySQL and it's fine. Choose your database on the features you need. Hard to compare MySQL and Postgres. Better to compare Postgress to SQl Server.
#WolfmanDragon
PostgreSQL has (tiny) support for objects, but it is, by nature, a relational database. From its about page:
PostgreSQL is a powerful, open source relational database system.
MySQL is a relational database management system while PostgreSQL is an object-relational database management system. PostgreSQL is suited well for C++ or Java developers, as it gives us more control over how queries are written. ORDBMS also gives us Objects and User Defined Types. The SQL queries themselves are much closer to the ISO standards than MySQL.
Do you need an ORDBMS or a RDBMS? That will better answer your question.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm an ASP.NET developer who has used Microsoft SQL Server for all my database needs (both at work and for personal projects).
I am considering trying out the LAMP stack for some of my personal projects.
What are some of the main differences between MySQL and SQL Server? Is using stored procedures a common practice in MySQL?
Any advice or resources you'd recommend to help me with the switch?
To those who have experience with both, are there any missing features from MySQL?
One thing you have to watch out for is the fairly severe differences in the way SQL Server and MySQL implement the SQL syntax.
Here's a nice Comparison of Different SQL Implementations.
For example, take a look at the top-n section. In MySQL:
SELECT age
FROM person
ORDER BY age ASC
LIMIT 1 OFFSET 2
In SQL Server (T-SQL):
SELECT TOP 3 WITH TIES *
FROM person
ORDER BY age ASC
Lots of comments here sound more like religious arguments than real life statements.
I've worked for years with both MySQL and MSSQL and both are good products.
I would choose MySQL mainly based on the environment that you are working on. Most open source projects use MySQL, so if you go into that direction MySQL is your choice. If you develop something with .Net I would choose MSSQL, not because it's much better, but just cause that is what most people use.
I'm actually currently on a Project that uses ASP.NET with MySQL and C#. It works perfectly fine.
I can't believe that no one mentioned that MySQL doesn't support Common Table Expressions (CTE) / "with" statements. It's a pretty annoying difference.
MySQL is more likely to have database corruption issues, and it doesn't fix them automatically when they happen. I've worked with MSSQL since version 6.5 and don't remember a database corruption issue taking the database offline. The few times I've worked with MySQL in a production environment, a database corruption issue took the entire database offline until we ran the magic "please fix my corrupted index" thing from the commandline.
MSSQL's transaction and journaling system, in my experience, handles just about anything - including a power cycle or hardware failure - without database corruption, and if something gets messed up it fixes it automatically.
This has been my experience, and I'd be happy to hear that this has been fixed or we were doing something wrong.
http://dev.mysql.com/doc/refman/6.0/en/corrupted-myisam-tables.html
http://www.google.com/search?q=site%3Abugs.mysql.com+index+corruption
Everything in MySQL seems to be done closer to the metal than in MSSQL, And the documentation treats it that way. Especially for optimization, you'll need to understand how indexes, system configuration, and the optimizer interact under various circumstances.
The "optimizer" is more a parser. In MSSQL your query plan is often a surprise (usually good, sometimes not). In MySQL, it pretty much does what you asked it to do, the way you expected it to. Which means you yourself need to have a deep understanding of the various ways it might be done.
Not built around a good TRANSACTION model (default MyISAM engine).
File-system setup is your problem.
All the database configuration is your problem - especially various cache sizes.
Sometimes it seems best to think of it as an ad-hoc, glorified isam. Codd and Date don't carry much weight here. They would say it with no embarrassment.
Frankly, I can't find a single reason to use MySQL rather than MSSQL. The issue before used to be cost but SQL Server 2005 Express is free and there are lots of web hosting companies which offer full hosting with sql server for less than $5.00 a month.
MSSQL is easier to use and has many features which do not exist in MySQL.
I think one of the major things to watch out for is that versions prior to MySQL 5.0 did not have views, triggers, and stored procedures.
More of this is explained in the MySQL 5.0 Download page.
Both are DBMS's Product Sql server is an commercial application while MySql is an opensouces application.Both the product include similar feature,however sql server should be used for an enterprise solution ,while mysql might suit a smaller implementation.if you need feature like recovery,replication,granalar security and significant,you need sql server
MySql takes up less spaces on disk, and uses less memory and cpu than does sql server
#abdu
The main thing I've found that MySQL has over MSSQL is timezone support - the ability to nicely change between timezones, respecting daylight savings is fantastic.
Compare this:
mysql> SELECT CONVERT_TZ('2008-04-01 12:00:00', 'UTC', 'America/Los_Angeles');
+-----------------------------------------------------------------+
| CONVERT_TZ('2008-04-01 12:00:00', 'UTC', 'America/Los_Angeles') |
+-----------------------------------------------------------------+
| 2008-04-01 05:00:00 |
+-----------------------------------------------------------------+
to the contortions involved at this answer.
As for the 'easier to use' comment, I would say that the point is that they are different, and if you know one, there will be an overhead in learning the other.
Anyone have any good experience with a
"port" of a database from SQL Server
to MySQL?
This should be fairly painful! I switched versions of MySQL from 4.x to 5.x and various statements wouldn't work anymore as they used to. The query analyzer was "improved" so statements which previously were tuned for performance would not work anymore as expected.
The lesson learned from working with a 500GB MySQL database: It's a subtle topic and anything else but trivial!
#Cebjyre. The IDE whether Enterprise Manager or Management Studio is better than anything I have seen so far for MySQL. I say 'easier to use' because I can do many things in MSSQL where MySQL has no counterparts. In MySQL I have no idea how to tune the queries by simply looking at the query plan or looking at the statistics. The index tuning wizard in MSSQL takes most of the guess work on what indexes are missing or misplaced.
One shortcoming of MySQL is there's no max size for a database. The database would just increase in size till it fills up the disk. Imagine if this disk is sharing databases with other users and suddenly all of their queries are failing because their databases can't grow. I have reported this issue to MySQL long time ago. I don't think it's fixed yet.
Spending some time working with MySQL from the MSSQL to MySQL syntax POV I kept finding myself limited in what I could do.
There are bizzare limits on updating a table while refrencing the same table during an update.
Additionally UPDATE FROM does not work and last time I checked they don't support the Oracle MERGE INTO syntax either. This was a show stopper for me and I stopped thinking I would get anywhere with MySQL after that.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
We are currently using MySQL for a product we are building, and are keen to move to PostgreSQL as soon as possible, primarily for licensing reasons.
Has anyone else done such a move? Our database is the lifeblood of the application and will eventually be storing TBs of data, so I'm keen to hear about experiences of performance improvements/losses, major hurdles in converting SQL and stored procedures, etc.
Edit: Just to clarify to those who have asked why we don't like MySQL's licensing. We are developing a commercial product which (currently) depends on MySQL as a database back-end. Their license states we need to pay them a percentage of our list price per installation, and not a flat fee. As a startup, this is less than appealing.
Steve, I had to migrate my old application the way around, that is PgSQL->MySQL. I must say, you should consider yourself lucky ;-)
Common gotchas are:
SQL is actually pretty close to language standard, so you may suffer from MySQL's dialect you already know
MySQL quietly truncates varchars that exceed max length, whereas Pg complains - quick workaround is to have these columns as 'text' instead of 'varchar' and use triggers to truncate long lines
double quotes are used instead of reverse apostrophes
boolean fields are compared using IS and IS NOT operators, however MySQL-compatible INT(1) with = and <> is still possible
there is no REPLACE, use DELETE/INSERT combo
Pg is pretty strict on enforcing foreign keys integrity, so don't forget to use ON DELETE CASCADE on references
if you use PHP with PDO, remember to pass a parameter to lastInsertId() method - it should be sequence name, which is created usually this way: [tablename]_[primarykeyname]_seq
I hope that helps at least a bit. Have lots of fun playing with Postgres!
I have done a similar conversion, but for different reasons. It was because we needed better ACID support, and the ability to have web users see the same data they could via other DB tools (one ID for both).
Here are the things that bit us:
MySQL does not enforce constraints
as strictly as PostgreSQL.
There are different date handling routines. These will need to be manually converted.
Any code that does not expect ACID
compliance may be an issue.
That said, once it was in place and tested, it was much nicer. With correct locking for safety reasons and heavy concurrent use, PostgreSQL performed better than MySQL. On the things where locking was not needed (read only) the performance was not quite as good, but it was still faster than the network card, so it was not an issue.
Tips:
The automated scripts in the contrib
directory are a good starting point
for your conversion, but will need
to be touched a little usually.
I would highly recommend that you
use the serializable isolation
level as a default.
The pg_autodoc tool is good to
really see your data structures and
help find any relationships you
forgot to define and enforce.
We did a move from a MySQL3 to PostgreSQL 8.2 then 8.3. PostgreSQL has the basic of SQL and a lot more so if your MYSQL do not use fancy MySQL stuff you will be OK.
From my experience, our MySQL database (version 3) doesn't have Foreign Key... PostgreSQL lets you have them, so we had to change that... and it was a good thing and we found some mistake.
The other thing that we had to change was the coding (C#) connector that wasn't the same in MySQL. The MySQL one was more stable than the PostgreSQL one. We still have few problems with the PostgreSQL one.