Re: Continuous Informix to Postgres data replicati
Posted in 2013
Art, Thanks for the licensing info, I'll keep that in mind. However, my product is already past 1.0 stage and changing the core database is going to be challenging. Definitely a long term issue. Running against the existing Informix database is one of supported deployment scenarios, but unfortunately it does not scale. The legacy application is built around Informix and is tightly integrated with it, so basically the only option to make it support more users is to get a bigger iron, and there are limits at how big you can go with just one box. I thought that if I could replicate that data to the database on my side, that would solve the problem - my app scales much better and it's possible to have a separate box/cluster for DB and parallelize the middleware. Not much help with that if the queries are still going to hit the original Informix DB. Another problem with the legacy app's poor scalability is the fragmentation it causes. If you can't have more than X simultaneous users per server, you will get Y legacy servers. The data is completely independent, and that causes a lot of headache. Replicating that data to my side, combined with index mapping, would solve this problem as well. Finally, the legacy app has hardcoded limits for data retention, which was very reasonable 20+ years ago when it was developed but is totally ridiculous now. The only way I see to make the data available longer is to replicate it to my DB. I'm not trying to say that none of the above can be implemented in Informix, quite to the contrary, some things are done a lot easier and more robust in Informix than in Postgres. But it comes with a price tag, and quite hefty one. From my understanding, it will be very hard to find standard tooling solution to the above problems with Informix IE, it's either more advanced (and expensive) editions, or custom code. And if I have to write custom code, I may as well go with the free Postgres and keep my software more affordable. Regards, Alex.