Connecting Redshift

Neuralift connects to Amazon Redshift with a database user you provide, over the cluster’s standard endpoint. This page walks through creating that user, opening the network path, adding the connection, and — when runs are published — receiving results as Parquet files in your own S3 bucket, ready to COPY into Redshift (Receiving results in Redshift).

How this connection works

Neuralift connects the same way any SQL client does: over your cluster’s standard JDBC/ODBC endpoint, authenticated as the database user you create for it. Grant that user read access to only the schemas Neuralift needs; your cluster’s network rules decide reachability, and dropping the user or its grants on your side severs the connection at any time. Authentication is database user and password only — IAM-based authentication isn’t supported for this connection.

Before you begin

• You need the admin role in your Neuralift organization; see Roles & permissions.
• In Redshift you need a superuser (or a user who can CREATE USER and grant on the relevant schemas), and whoever manages the cluster’s networking.
• Neuralift does not accept any data with PII. Check Data requirements before connecting tables.

Create a database user

Create a dedicated user for Neuralift and grant it read access to the schemas that hold your source tables:

CREATE USER neuralift_svc PASSWORD '<strong-generated-password>';

GRANT USAGE ON SCHEMA analytics_schema TO neuralift_svc;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics_schema TO neuralift_svc;

-- keep tables created later readable without re-granting
ALTER DEFAULT PRIVILEGES IN SCHEMA analytics_schema
  GRANT SELECT ON TABLES TO neuralift_svc;

Repeat the grants per schema to scope the user to exactly what Neuralift should see.

Open the network path

The cluster endpoint must be reachable by Neuralift’s compute layer. The standard arrangement is a publicly accessible cluster with a security-group inbound rule allowing Neuralift’s egress IPs on the cluster port (default 5439); your Neuralift contact can provide the current IP list. If your cluster is locked to a private network, work with your network team and your Neuralift contact on an equivalent arrangement.

Add the connection

1. In Neuralift, go to Settings → Data Connections and click Add connection.
2. Under Warehouse type, select Redshift.
3. Enter a Connection name (lowercase letters, digits, and dashes; unique within your organization).
4. Enter the Host: your cluster endpoint, for example <cluster>.<id>.<region>.redshift.amazonaws.com.
5. Confirm the Port. It defaults to 5439, Redshift’s standard port.
6. Enter the Database that contains your source tables, for example <analytics>.
7. Enter the Username and Password of the user you created above.
8. Click Save & connect.

The dialog closes and a Setting up … connection… notice appears. After a moment the new connection card appears with an Active badge (or Error with an explanation) and gains Browse tables and Test buttons.

To rotate the credential later, change the password in Redshift, then re-save the connection in Neuralift with the new password — it rotates in place, with no need to remove and re-add the connection.

Receiving results in Redshift

Results are delivered as Parquet files pushed to an S3 bucket you own; loading them into Redshift is then a single COPY on your side. There are no long-lived credentials in either direction: Neuralift’s delivery service assumes a dedicated per-organization IAM role via STS, and the only grant on your side is a bucket policy naming that role. The delivery workflow around it is covered in Delivering results to your warehouse.

1. Under Settings → Data Connections → Share your results, choose Cloud storage and enter your destination, s3://<bucket>/<prefix>.
2. Neuralift creates a dedicated IAM role for your organization in Neuralift’s AWS account, and the settings panel renders a ready-made bucket policy JSON statement naming that role’s ARN.
3. Have whoever administers your AWS account attach the statement to the bucket’s policy. It grants the role bucket metadata and list access scoped to your prefix (s3:ListBucket, s3:GetBucketLocation) plus the object operations it needs to manage deliveries under it (s3:PutObject, s3:DeleteObject, s3:AbortMultipartUpload, s3:ListMultipartUploadParts). Deliveries fail until the policy is in place.
4. Each published run your Neuralift team delivers lands as Parquet files under s3://<bucket>/<prefix>/<run_id>/segment_labeled_data/.
5. Load a run into Redshift with COPY, using your own IAM role that can read the bucket:

COPY analytics_schema.neuralift_segments
FROM 's3://<bucket>/<prefix>/<run_id>/segment_labeled_data/'
IAM_ROLE 'arn:aws:iam::<your-account>:role/<your-redshift-role>'
FORMAT AS PARQUET;

Things to know:

• Customer-managed KMS keys need one extra grant. If the bucket is encrypted with your own KMS key, Neuralift’s delivery role also needs encrypt permission on that key — add its ARN (from the rendered bucket policy) to the key’s policy; the bucket policy alone doesn’t cover it.
• Removing the delivery configuration doesn’t recall files. Anything already delivered stays in your bucket until you delete it.
• The COPY role is yours, not Neuralift’s. The role in the COPY statement is an IAM role in your account, attached to your cluster, with read access to the bucket — separate from the delivery role in the bucket policy.

Troubleshooting

• The connection lands on Error. The card shows an explanation. Common causes: the Host or Port is wrong or unreachable from outside your network, the Database name is misspelled, or the username and password were rejected.
• The connection is Active but expected tables are missing. The Redshift user can only expose what it can read. Grant it access to the schemas you need, then use Sync tables in the Source tables sheet to re-discover them.
• Redshift isn’t offered as a warehouse type. Redshift connections and delivery are enabled per organization on request; see Release stages and contact support@neuralift.ai to request access.

Note. Credentials are used to provision the connection and are handled as described in Data handling & security.

Next steps

• Sync source tables from your new connection.
• Review data requirements so your tables are ready for segmentation.
• When runs are published, see Delivering results to your warehouse for the delivery workflow.