4 ms·
How big was the application (like how many developers were involved in the migration, data size, etc)? How long did the migration take? Was the business okay w
by BrentOzar 13y ago
How big was the application (like how many developers were involved in the migration, data size, etc)?
How long did the migration take? Was the business okay with a feature freeze during that time, or did you take advantage of the switch to rewrite it too?
Did you have multiple connected systems, like ETL processes that also hit the database for other reporting systems?
Always curious about these kinds of issues because they seem to be what's holding businesses back.
- deleted 13y ago[deleted]
- Herbert2 13y agoI went through a similar switch from MSSQL to postgres. We moved 7 applications of various sizes over and the biggest hurdle was office politics. The migration never took more than a day for each app. ETL and reporting were not affected since we had previously integrated messaging (rabbitmq) pretty heavily into every system at the company and ETL gets their data from there. We also switched the DB servers to over to linux and got a huge performance boost from that. We did rewrite some stuff, but that was mostly to take advantage of postgres features like array types (instead of a article tags table, you'd have an tags array) which we used to speed up some applications. One we sped up by a factor of 10, just by using array types and offloading json generation to postgres: select array_to_json(array_agg(row_to_json(t))) from ( some query ) t
- taude 13y agoIt was several smaller apps written with most logic in the app (Hibernate) and had very little T-SQL/stored procs. We also weren't using any of the add-ons like SQL reporting, etc. The big commercial DBs have the advantages when you start using their reporting services, BI/OLAP stuff...and likely when you have several different groups as stakeholders in the process...