The Postgres Plus Cloud Database was announced early this year.
As I do not have a lot of experience on database clustering, I am wondering which one I should use. Can anyone give me a compare between Postgres Plus Cloud Database and Amazon RDS in terms of features, cost and maintenance?
The requirements for our applications are:
high availability.
There will be very low load for our application.
Thanks!
PostgreSQL is not (yet) supported by Amazon RDS. So it's not easy to answer your question.
In any case: Heroku could be an alternative to Postgres Plus Cloud Database.
PostgreSQL is now supported in Amazon RDS!
See the blogpost here:
http://aws.typepad.com/aws/2013/11/amazon-rds-for-postgresql-now-available.html?sc_ichannel=EM&sc_icountry=Global&sc_icampaign=reinvent1114&sc_idetail=55698910&ref_=13
Related
Since Citus is not going to be available as a Managed Service in AWS, I am trying move the database to RDS (not the whole history but only the transactional portion as an OLTP). The migration from Citus is not clear because the data does not reside in a single node. I want to check the options we might have to move data from Citus to RDS.
Amazon DMS: This option is good for the supported databases (PostgreSQL) but we do not know what behavior this will have in Citus from the distributed nature of the engine. Has someone migrated the data to S3, to another DB or something in these lines?
I saw this paper from AWS https://d1.awsstatic.com/whitepapers/aws-cloud-data-ingestion-patterns-practices.pdf?did=wp_card&trk=wp_card on how to ingest data from different sources and DMS seems like a good option but I do not know the internals of Citus that well to tell if we will get all the data and gather the CDC correctly.
A Custom migration: Via a support ticket, we can access the S3 buckets that Citus uses for Disaster recovery where the WAL logs are available and we could use something like WAL-G to take those logs and replicate them in a Postgres instance. The issue here is that this is a very custom migration and the development time might be too high.
Is there any other option to move data from Citus to RDS or Aurora in AWS, what looks like a good path to make the database migration? All the documents refer to move data the other way around, from Aurora or RDS to Citus.
Sumedh from Citus Cloud here. Please go ahead and open a support ticket with us to further investigate solutions. We can evaluate if using DMS is a viable approach for your use-case.
We are managing to use GCP CloudSQL for our PostgreSQL database,
at this moment one of our applications uses large objects and i was wondering how to perform a vacuumlo operation on such platforms (question might be valid for AWS RDS or any other cloud postgresql provider).
Does making custom queries/procedures to perform the same task is the only solution?
Since vacuumlo is a client tool, it should work just fine with hosted databases.
I can read in thingsboard configuration documentation (https://thingsboard.io/docs/user-guide/install/config/), in "Common database parameters" section, that database.ts.type can be sql or cassandra, and cassandra should be used for hybrid mode. what's that hybrid mode?
Do you mean that database.entities.type can be sql (postgres) and database.ts.type can be cassandra? and
vice versa?
what's the recommanded install? All on cassandra?
Many thanks,
Best regards
Found the answer here:
https://thingsboard.io/docs/reference/ , section "SQL vs NoSQL vs Hybrid database approach"
ThingsBard uses database to store entities (devices, assets, customers, dashboards, etc) and telemetry data (attributes, timeseries sensor readings, statistics, events). Platform supports three database options at the moment:
SQL - Stores all entities and telemetry in SQL database. ThingsBoard authors recommend to use PostgreSQL and this is the main SQL database that ThingsBoard supports. It is possible to use HSQLDB for local development purposes. We do not recommend to use HSQLDB for anything except running tests and launching dev instance that has minimum possible load.
NoSQL - Stores all entities and telemetry in NoSQL database. ThingsBoard authors recommend to use Cassandra and this is the only NoSQL database that ThingsBoard supports at the moment. However, due to a lot of interest to deployments with managed databases, we plan to introduce support on AWS DynamoDB in v2.3.
Hybrid - Stores all entities in SQL database and all telemetry in NoSQL database.
I have a database in PostgreSQL. Now we need to import whole database into DynamoDB. Data Migration service need to be used for this purpose or any other service can be used. Please explain in detail.
What is the strategy to be followed? I have studied many blogs but I couldn't get any proper way to migrate the whole database from PostgreSQL to DynamoDB. Only through DMS Service is it possible to migrate or any other service can be used to migrate or any script should be run to migrate the PostgreSQL to to DynamoDB.
The AWS Database Migration Service offers everything you would need to migrate data from any relational DB into AWS - whether the target is DynamoDB (NoSQL offering from AWS) or any of the DB flavors from AWS RDS service.
You can find multiple migration playbooks and step-by-step guides on the Resources page of this AWS service
I have an OLTP DB in Oracle and a downstream OLAP System in PostgreSQL on-premises. The data from Oracle is pumped into PostgreSQL using Oracle_FDW.
I am exploring the possibility of moving the PostgreSQL to AWS, but none of the RDS have Oracle_fdw capability. One way out is to install PG on an EC2 instance but that would leave some of the features like read-replica provided natively by AWS. Is there a better workaround?
Also is there a way to fetch the data in Oracle RDS from Postgres RDS in AWS?
With PostgreSQL on Amazon RDS your choice of extensions is limited to the extensions they explicitly support. As far as I'm aware there's no way around this limitation.
Like you mentioned, the general option in this case would be to host PostgreSQL yourself on EC2 instead of RDS. You lose automatic backup/replication/management features, but you get the power and flexibility you need. This will certainly work but will require some leg work to replace what you're losing by not using RDS.
The only alternative to this I can think of is that you may be able to host a different (otherwise empty) PostgreSQL server with the oracle-fdw extension installed and use the postgres-fdw extension (which is supported by RDS) to proxy requests from your RDS hosted database, through your proxy PostgreSQL database, to your Oracle database and back. If the amount of data you're retrieving is substantial, or if the number of queries per minute is high this is probably a terrible idea. But it might be worth testing to see if it works for your use case.
I did a quick search around and I haven't been able to find any references to anyone actually layering foreign data wrappers like this but I also couldn't find anything in the manual or online saying it wasn't supported either. In theory it should work, but if you do try it make sure you thoroughly test it prior to using it to do anything important.
Oracle_FDW is now supported in recent versions - https://aws.amazon.com/about-aws/whats-new/2021/07/amazon-rds-for-postgresql-supports-oracle-fdw-extension-for-accessing-data-in-oracle-databases/