Netsuite to Amazon Redshift: How to Move Your Data
Move NetSuite into Amazon Redshift with Airbyte. The enterprise connector tier, assembling token based authentication, and why a view layer comes first.
Moving NetSuite into Amazon Redshift takes the system running your finances and puts a copy where analysts can work without waiting for somebody to build a saved search. NetSuite holds the authoritative record of what was sold, invoiced and paid, and reporting against it directly is slow and limited.
Two things shape this build. The credential chain needs an administrator and four values from two places, and Redshift cannot be loaded without a staging bucket, which adds an AWS prerequisite to an ERP pipeline.
NetSuite to Amazon Redshift at a glance:
Why move data from NetSuite to Amazon Redshift?
Two situations account for most of these pipelines.
The first is analysis NetSuite's own reporting cannot do. Multi-year trends, custom cohort definitions and anything requiring a join across several record types are awkward in saved searches and ordinary in a warehouse.
The second is joining ERP data to the rest of an AWS estate. If your product events, marketing sources and support data already live there, bringing financial records across puts everything in reach of one set of queries rather than an export somebody emails around.
What do you need before you start?
One commercial conversation, a credential chain that needs an administrator, and an AWS prerequisite:
An Airbyte agreement covering this connector. NetSuite is a premium enterprise connector available at an additional cost, so it is not something you switch on from the catalogue. The NetSuite source documentation covers what it includes.
Token based authentication enabled, and four credential values. Switched on under setup, company and enable features, on the SuiteCloud tab. An integration record gives you a consumer key and secret, and an access token gives you a token ID and secret. Each is displayed once.
Your realm, which is the account ID. Found in your NetSuite account settings. Sandbox accounts carry a suffix, so a realm copied from a test environment will not work against production.
An S3 staging bucket and Redshift entities. The destination writes data to S3 as files with a manifest, then issues a COPY command. You need put, get, delete and list on the bucket in your cluster's region, plus a database, schema and user able to manage staging operations.
Note also that an SSH tunnel covers the SQL connection only. Staging traffic reaches S3 over HTTPS regardless, so a network design assuming everything passes through a bastion is wrong.
How do you build a NetSuite to Amazon Redshift pipeline in Airbyte?
Step 1: Get an administrator and scope the role
Book time with whoever administers NetSuite, because the whole credential chain needs them. While you have their attention, decide what the integration role can see, since that role defines the boundary of your dataset and widening it later means going back to them.
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, consumer key and secret, token ID and secret, and a start date. Then refresh the source schema and look at what appeared, because a NetSuite catalogue reflects that specific account's configuration.
Step 3: Configure the Redshift destination
Click Destinations, then New Destination, and select Redshift, following adding a destination. Supply the cluster host, database, schema and credentials, along with your S3 bucket and IAM key. Staging files are removed after a successful COPY by default, and can be retained if you need them for debugging.
Step 4: Select records deliberately and set your keys
Click Connections, then New connection, and select streams with a sync mode. Take what your reporting needs rather than everything available, and set sort keys on transaction dates, since financial queries are almost always filtered by period.
Reconcile a closed period against NetSuite before anyone builds on the data, because this is the system of record for figures somebody is accountable for.
Why does no two NetSuite accounts look alike?
Because NetSuite is configured rather than merely used. Custom fields, custom record types and renamed standard fields are normal practice, and an implementation partner will have spent months shaping the account around how that business works.
So the catalogue you see is specific to your account, and generic guidance about which streams to take is worth less here than almost anywhere else. The person who knows what a custom field actually means is whoever configured it, and that conversation is part of the build rather than optional background.
Document what you took and why, because the next person to touch this pipeline will not be able to work it out from the field names alone. On a source where a column called custentity numbers can be the single most important attribute in the business, that documentation is the difference between a maintainable pipeline and an unreadable one.
Why build a view layer immediately?
Because what lands is not what anybody wants to query. Airbyte writes into two schemas, adds its own metadata columns, and preserves NetSuite's internal field names, so the raw tables carry both the connector's plumbing and an ERP's naming conventions at the same time.
A view resolves all of it in one place. Custom fields get readable names, metadata columns disappear, and the two-schema arrangement stops being something every analyst has to understand. That is worth doing before anybody writes their first report rather than after.
It also protects you from the source changing. NetSuite accounts get reconfigured, and a renamed custom field becomes a view edit rather than a hunt through every report that referenced it. On a row-oriented warehouse with no semi-structured middle ground, that modelled layer is where the dataset becomes usable.
Frequently asked questions
Is the NetSuite connector included in my plan?
It is a premium enterprise connector available at an additional cost, so it needs a commercial conversation rather than a configuration change.
Why will the connector not authenticate?
Check token based authentication is enabled in NetSuite, then check the realm, since sandbox account IDs carry a suffix and will not work against production.
Do I need an S3 bucket to load into Redshift?
Yes. The destination stages data in S3 and loads it with COPY, which is Redshift's recommended approach. Put the bucket in the same region as your cluster.
Why does my catalogue look different from the documentation?
Because NetSuite accounts are heavily customised. Custom record types and fields are normal, so your catalogue reflects your own configuration rather than a standard shape.
Can I do this without writing code?
Yes. The setup is UI-driven on both sides, though the NetSuite half needs an administrator. You will want Redshift views giving custom fields readable names.
Get your NetSuite data into Amazon Redshift
Book the administrator early because the credential chain depends on them, and provision the staging bucket in your cluster's region. Take only the records you need, build the view layer before anybody writes a report, and reconcile a closed period before anyone relies on it.
Airbyte's connector catalog includes 700+ pre-built connectors, so ERP data can sit beside the commercial sources that explain it. For the same source in another warehouse, see NetSuite to Snowflake, and for payment data alongside it, Stripe to Amazon Redshift.
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.