What a Real Two-Way Sync Between Amazon RDS and NetSuite Takes

What two-way sync between Amazon RDS and NetSuite has to solve

A one-way pipeline has a single job: read from a source, write to a target, keep up. Almost everything it can get wrong is a throughput problem, and throughput problems have familiar answers. Bidirectional sync adds a set of problems that have nothing to do with throughput, and they are the reason most write-back projects run long.

• Write-back. Reading NetSuite is a query. Writing to NetSuite is a transaction against a system with validation rules, mandatory fields, posting periods and locked records. The read path tells you almost nothing about how the write path will behave.
• Echo suppression. Every write the engine makes into RDS shows up in the write-ahead log a moment later and looks exactly like a human edit. Unless the engine recognises its own writes, it picks them up and sends them back to NetSuite, which emits another change, and the record bounces.
• Conflict resolution. When the same field moves on both sides inside the same window, something has to decide the winner. Last writer wins makes that decision a function of job scheduling. Field-level precedence makes it a function of who owns the field.
• Idempotency and retry. ERP writes fail for ordinary reasons: a throttle, a timeout, a temporarily locked record. A retry has to update the same record rather than create a second one, which means a stable external key on both sides.
• Referential order. A sales order cannot reference a customer that does not exist yet. The engine has to hold the child until the parent lands rather than firing both and letting one fail.
• Rejection handling. When NetSuite refuses a write, that refusal is information. It needs to reach a person with the ERP's own error attached, not vanish into a log file.

None of those six are exotic. They are the standard content of every real bidirectional integration, which is why the general pattern is worth understanding before the specific one. The worked examples in bi-directional sync explained cover the same mechanics on other pairs.

What Amazon RDS changes about the database side

Amazon RDS is a managed relational database service. It runs PostgreSQL, MySQL, MariaDB, SQL Server, Oracle and Db2, and Aurora is a separate service with its own storage engine. Managed is the operative word: you get the engine you know, minus the parts of it that assume you are root on the host. That changes how change data capture gets set up, and it introduces one failure mode that will take an instance down if nobody is watching.

There is no superuser on an RDS instance. The master user is granted the rds_superuser role on Postgres, which is broad but not unlimited, and only AWS-supported extensions can be installed. Anything a self-managed CDC setup does by editing postgresql.conf and restarting has to be done through a custom DB parameter group instead.

For Postgres, logical replication is off by default. Turning it on means creating a custom parameter group, setting the flag, attaching it to the instance and rebooting, because the setting is static. The replication user also needs the right role.

-- Postgres on RDS: set in a CUSTOM DB parameter group, then reboot
--   rds.logical_replication = 1

-- then grant the role the CDC user needs
GRANT rds_replication TO sync_user;

-- MySQL on RDS: row-based binlog, and keep it long enough to recover
CALL mysql.rds_set_configuration('binlog retention hours', 72);

Enabling logical replication also creates the risk worth planning for. A replication slot holds the write-ahead log until the consumer confirms it has read past that point. If the consumer stops, the slot stops advancing and the WAL keeps accumulating on the instance's storage. Long enough and the instance runs out of disk, which stops writes to the production database. The failure did not start in the database. It started in whatever was reading from it. Any sync platform pointed at RDS has to advance its slot reliably, alert when lag grows, and clean up slots it abandons.

Connections are the other constraint. The default max_connections on RDS scales with the instance class, so a small instance has a modest ceiling, and a sync engine that opens a connection per worker competes with the application for it. RDS Proxy in front of the instance keeps pooling under control, which matters more once a second system is writing into the database on a steady cadence.

RDS instances also live inside a VPC, so any external service needs a deliberate network path: a peering connection, PrivateLink, or an allowlisted route. Add IAM database authentication and KMS encryption at rest and the security review is straightforward, but the path has to be designed rather than assumed. The same set of constraints shows up in any RDS integration, including syncing Amazon RDS with Salesforce.

What NetSuite changes about the ERP side

NetSuite offers several ways in. SuiteTalk exposes both a SOAP web services API and a REST record service. RESTlets are custom SuiteScript endpoints you deploy yourself, which is how teams handle records or behaviour the standard APIs do not cover well. SuiteQL runs SQL-style queries against NetSuite records, which is efficient for reads and irrelevant for writes.

The constraint that shapes every design is governance. SuiteScript charges usage units per operation, and a script that exceeds its allowance is stopped. NetSuite also caps how many concurrent requests an account may run, shared across every integration you have. A write path that opens as many parallel requests as it likes will either be throttled or will starve the scheduled scripts and interactive users that need the same budget. Treat the limit as a design input: batch where the API supports it, hold your own concurrency below the account ceiling, and back off on a throttle rather than hammering.

Then there is order. NetSuite records depend on each other, and the dependencies are strict. A sales order needs its customer to exist. A customer payment needs its invoice. An item fulfilment needs its order. A pipeline that pushes records in the order it happened to read them from a database will fail on roughly the fraction of them whose parents have not landed yet, and those failures look random until somebody notices the pattern.

Rejections are the third piece. NetSuite will refuse a write for missing mandatory fields, a closed posting period, a failed validation, or a record another process has locked. The ERP is right to refuse, and the error text usually says exactly what is wrong. The integration's job is to keep that write in a retry queue where retrying helps, and to surface it with the ERP's own message where it does not. Silently dropping it is how a database ends up quietly disagreeing with the ledger. For more on the read side of the same system, see second-level NetSuite change data capture.

What actually happens to a single record

The pieces are easier to hold together as the states one record passes through, rather than as a set of jobs and schedules.

Three of those states are the whole argument. Held in order is dependency handling. Backing off is governance handling. Rejected is the case a one-way pipeline never had to think about, because it never wrote to a system with an opinion. A design that only draws the happy path will meet all three in its first week of production.

How to choose, and what to check first

Start from latency and volume, because they rule options out quickly. If the RDS copy only feeds dashboards and nothing writes back, you do not need a two-way sync and a nightly extract is fine. The comparison in real-time sync versus batch ETL is the right frame for that decision. The moment an application writes to RDS and that value has to reach NetSuite, batch stops working, because a value that arrives tomorrow morning is not a value anyone can act on.

Then count the record types and name an owner for every field on each one. Two record types with a clean owner split is a custom-code project. Eight record types where finance owns the terms and an application owns the fulfilment fields is a platform decision, and the field-level ownership map you just wrote is exactly the conflict policy you will configure.

Whatever you pick, four checks are worth running before it reaches production. Confirm the engine advances its RDS replication slot and alerts on lag, so a stalled consumer cannot fill the instance's storage. Confirm every write into NetSuite carries an idempotency key, so a retry updates rather than duplicates. Confirm writes the engine makes into RDS are recognised as its own and not re-emitted. And confirm a rejected NetSuite write reaches a person with the ERP's error text attached.

To see Amazon RDS and NetSuite kept in step in both directions, book a demo, look at the Amazon RDS and NetSuite integration, or read the wider guide to NetSuite two-way sync solutions.