Netsuite to MySQL: How to Move Your Data
Move NetSuite into MySQL with Airbyte. Why four credentials come from two screens, why no two catalogues match, and why applications should read views.
Moving NetSuite into MySQL gives applications a place to read business records without waiting on an ERP. NetSuite holds the authoritative version of customers, orders and invoices, and it is neither fast nor cheap to query repeatedly from an internal tool that just needs to show somebody an order status.
This guide covers the managed path with Airbyte. Two things shape the build: authentication needs four credentials gathered from two different places, and no two NetSuite accounts contain the same things, so the catalogue you get is specific to your own customisation.
Netsuite to MySQL at a glance:
Why move data from Netsuite to MySQL?
Two situations account for most of these pipelines.
The first is serving applications. Internal tools, customer portals and operational dashboards want to look up an order or a customer quickly, and pointing each of them at NetSuite means API calls, governance limits and a dependency on the ERP being responsive. A MySQL copy answers those lookups in milliseconds and takes the load off a system that has other work to do.
The second is joining ERP records to data NetSuite knows nothing about, such as product usage or support history. The limit is scale and purpose. Guidance for this destination is around ten gigabytes, and heavy analytical work across years of transactions belongs somewhere columnar, so Netsuite to Snowflake is the better answer when the audience is analysts rather than applications.
What do you need before you start?
Four things, and the first two are a sequence rather than a list:
Token based authentication, switched on. It lives under Setup, then Company, then Enable Features, in the SuiteCloud section, and nothing else can happen until it is enabled. The NetSuite source documentation walks through the whole sequence.
Four credentials from two different screens. A consumer key and secret come from the integration record you create. A token ID and secret come from the access token you then issue against it. People routinely gather two of the four, try to connect, and assume the credentials are wrong rather than incomplete.
Your realm, with attention to the suffix. The realm is your account identifier, and a sandbox account carries a suffix that production does not. Building against sandbox and promoting later means changing this along with every credential, so plan that move rather than discovering it on the day.
A MySQL database and a view layer plan. The destination adds metadata columns, and NetSuite's custom fields produce column names nobody would choose. Agreeing now that applications read views rather than tables saves changing application code the first time somebody edits a field in NetSuite.
If your database restricts inbound traffic by IP, add the Airbyte Cloud IP addresses to the allow list before you begin.
How do you build a Netsuite to MySQL pipeline in Airbyte?
Step 1: Enable the feature, then collect all four credentials
Enable token based authentication first, because the screens that issue credentials do not appear until you have. Then create the integration record and keep its consumer key and secret, which are shown once. Then issue an access token and keep its token ID and secret, also shown once. Losing any of the four means starting that half again, so record them somewhere durable before closing the tab.
Step 2: Configure the Netsuite source
Click Sources in the left navigation, then New Source, and select NetSuite, following adding a source. Supply the realm and all four credentials, then look properly at what discovery returns. That list is your account's catalogue and it will not match anybody else's, so a colleague's configuration is a rough guide rather than a template.
Step 3: Configure the MySQL destination
Click Destinations, then New Destination, and select MySQL, following adding a destination. Supply the host, port, database and credentials. Give the pipeline its own database rather than mixing these tables into an application schema, since the naming and the metadata columns are not what an application developer expects to encounter.
Step 4: Create the connection and select narrowly
Click Connections, then New connection, select your streams and a sync mode. Take the records your applications actually read rather than everything discovery offered. A NetSuite account accumulates custom record types over years, most of which belong to a process nobody outside finance has thought about since 2019.
Then build the views before any application connects, because the first thing to read these tables sets the expectation for everything after it.
Why does every NetSuite catalogue look different?
Because NetSuite is configured rather than merely used. Custom record types, custom fields and custom forms are the normal way of working with it, so an account that has been live for five years holds a structure that reflects five years of decisions by people who mostly no longer work there. The connector reports what your account contains, which is why no two catalogues match.
This makes borrowed configuration unreliable. A stream list from another implementation, a colleague's notes, or a guide written against a demo account will all name things your account does not have and miss things it does. Discovery against your own realm is the only authority, and reading it carefully is worth more than any amount of preparation elsewhere.
It also means the sandbox is not a rehearsal. Sandbox and production drift apart as changes are made in one and not the other, and the realm suffix guarantees you will be changing configuration on promotion anyway. Verify your stream selection against production before anybody depends on it, and treat a sandbox build as a way to learn the mechanics rather than a finished configuration to copy across.
Why should applications read views rather than these tables?
Because the tables carry NetSuite's customisation directly into your application's data access layer. Custom fields arrive under the names NetSuite generated for them, which are rarely readable and were never chosen with a developer in mind, and the destination adds metadata columns of its own alongside. An application reading those tables is coupled to both.
That coupling is expensive because NetSuite keeps changing. Somebody in finance adds a field, renames one, or retires a custom record, and a column your application selects by name stops existing. With a view in between, that is one statement to update. Without it, the change reaches production code and the first person to know is whoever is on call.
The practical shape is one view per record type that applications use, selecting only the columns they need, renaming generated field names into something readable, and leaving the pipeline's metadata out. Watch the column names while you are there, since MySQL stops at 64 characters for an identifier and NetSuite's custom field naming can produce flattened names that come close. The view is where you notice that, and where you fix it once for everybody.
Frequently asked questions
Why will my credentials not authenticate?
Usually because only two of the four values are present. The consumer key and secret come from the integration record and the token ID and secret from the access token, and all four are required together.
Can I reuse my sandbox configuration in production?
Only as a starting point. The realm differs because sandbox carries a suffix, the credentials are separate, and the two accounts drift apart in what they contain. Re-run discovery against production.
Why does a guide list streams I do not have?
Because NetSuite accounts are heavily customised and the catalogue reflects yours specifically. Any list written against another account is approximate by nature.
What happens when somebody changes a field in NetSuite?
The column arriving in MySQL changes with it. A view between the tables and your applications turns that into one edit rather than a production incident.
Can I do this without writing code?
The pipeline, yes, and the NetSuite setup is all configuration. The views are modest SQL and they are what protects your applications from an ERP that changes without warning you.
Get your Netsuite data into MySQL
Enable the feature before hunting for credentials, and collect all four in one sitting since each is shown once. Run discovery against production and read it, because your catalogue belongs to your account and nobody else's notes describe it. Select narrowly, and put views between these tables and anything that reads them, so the next person to edit a field in NetSuite changes one statement rather than your application.
Airbyte's connector catalog includes 600+ pre-built connectors, so ERP records can reach the systems that need them without hammering the ERP. For the same source into another operational database, see Netsuite to PostgreSQL, and for another finance system into the same destination, Quickbooks to MySQL.
Integrate with 700+ apps using Airbyte
Move data from 700+ sources into warehouses, lakes, and beyond. Set up pipelines in minutes with pre-built connectors and the Connector Builder.