LocalStack Pro Aurora PostgreSQL Extension Bug: aws_lambda Schema Installation Issue

LocalStack Pro Aurora PostgreSQL Extension Bug: aws_lambda Schema Installation Issue

Aaron Rose  

Software Engineer & Technology Writer

Problem

When using LocalStack Pro to simulate AWS Aurora PostgreSQL with Lambda triggers, the aws_lambda extension appears to install successfully but doesn't work as expected. The extension command completes without errors, but calling functions like aws_commons.create_lambda_function_arn() fails with "schema does not exist" errors, even though the extension installation reported success.  This bug has been confirmed by multiple developers and reported to LocalStack support as of January 2025.

Clarifying the Issue

This is a confirmed bug in LocalStack Pro's Aurora PostgreSQL implementation. When you install the aws_lambda extension in a database other than the cluster's primary database, LocalStack exhibits incorrect behavior:

What should happen: All extension components (language support, schemas, and functions) install in the target database where you run CREATE EXTENSION.

What actually happens: The plpython3u language extension installs in your target database, but the aws_commons and aws_lambda schemas are incorrectly installed in the cluster's primary database instead.

This creates a split installation where your application code can't find the required functions, leading to confusing "schema does not exist" errors despite successful extension installation.

Why It Matters

• Silent failures: Extensions appear to install successfully but don't actually work
• Development inconsistency: Teams using different database names will have different experiences
• Debugging confusion: Developers waste time troubleshooting working code
• IaC reliability: Infrastructure scripts become unreliable when they assume consistent extension behavior
• Integration testing: Local Aurora → Lambda integration tests fail unexpectedly

This bug particularly impacts teams using LocalStack Pro for local AWS service integration testing.

Key Terms

• aws_lambda: PostgreSQL extension enabling Aurora to trigger AWS Lambda functions
• aws_commons: Schema containing utility functions like create_lambda_function_arn()
• plpython3u: Untrusted Python 3 language extension required for Lambda integration
• Primary database: The initial database created when the Aurora cluster is provisioned
• Target database: The database where you're running your application and installing extensions
• Schema split: Bug behavior where extension components install across multiple databases

Steps at a Glance

1. Create Aurora cluster with primary database name (e.g., main)
2. Connect to different database (e.g., dev)
3. Install aws_lambda extension - succeeds with no errors
4. Try calling aws_commons.create_lambda_function_arn() - fails with schema error
5. Verify schemas actually installed in primary database instead
6. Implement one of three workaround options (see detailed steps below)

Detailed Steps

Reproducing the Bug

Step 1: Create Aurora Cluster with Primary Database

bash

awslocal rds create-db-cluster \
  --db-cluster-identifier test-cluster \
  --engine aurora-postgresql \
  --database-name main \
  --master-username testuser \
  --master-user-password testpass

awslocal rds create-db-instance \
  --db-instance-identifier test-instance \
  --db-cluster-identifier test-cluster \
  --engine aurora-postgresql \
  --db-instance-class db.t3.medium

Step 2: Create Your Development Database

bash

# Connect to primary database first
psql "host=localhost port=5432 dbname=main user=testuser password=testpass"

# Create your dev database
CREATE DATABASE dev;
\q

Step 3: Connect to Development Database and Install Extension

bash

# Connect to your target development database
psql "host=localhost port=5432 dbname=dev user=testuser password=testpass"

sql

-- This will succeed without errors (misleading!)
CREATE EXTENSION IF NOT EXISTS aws_lambda CASCADE;

-- Check what actually installed in this database
\dx

You'll see only plpython3u listed, not aws_lambda or aws_commons.

Step 4: Attempt to Use Lambda Functions

sql

-- This will fail with "schema does not exist"
SELECT aws_commons.create_lambda_function_arn(
    'my-test-function',
    'us-east-1',
    '123456789012'
);

Step 5: Verify Where Schemas Actually Installed

bash

-- Switch to primary database
\c main

-- Check extensions here
\dx

You'll now see aws_lambda and aws_commons listed in the primary database.

Step 6: Implement Workaround (Choose One Option)

Option A: Use Primary Database for Extensions (Recommended)

bash

# Always connect to primary database for extension management
psql "host=localhost port=5432 dbname=main user=testuser password=testpass"

sql

-- Install extension in primary database
CREATE EXTENSION IF NOT EXISTS aws_lambda CASCADE;

-- Verify installation
\dx

-- Create your Lambda function ARN (this will work)
SELECT aws_commons.create_lambda_function_arn(
    'my-test-function',
    'us-east-1', 
    '123456789012'
);

-- If you need to use from other databases, you can reference cross-database
-- Note: This requires appropriate permissions and connection handling

Option B: Develop Against Primary Database

Update your application connection strings and IaC scripts to use the primary database name instead of creating separate development databases:

bash

# Update your app to connect to primary database
psql "host=localhost port=5432 dbname=main user=testuser password=testpass"

Option C: Contact LocalStack Support

Since this is a confirmed bug, report it to LocalStack Pro Support:

• Visit the LocalStack Slack #pro-support channel
• Reference this issue and provide reproduction steps
• Include your LocalStack Pro version and configuration
• Consider using real AWS Aurora for critical integration testing until fixed

Verification Steps

sql

-- Test that extension functions are accessible
SELECT aws_commons.create_lambda_function_arn(
    'test-function',
    'us-east-1',
    '123456789012'
) as function_arn;

-- Test creating a trigger (if you have a Lambda function set up)
CREATE OR REPLACE FUNCTION test_lambda_trigger()
RETURNS trigger AS $$
BEGIN
    PERFORM aws_lambda.invoke(
        aws_commons.create_lambda_function_arn('test-function', 'us-east-1', '123456789012'),
        '{"test": "data"}'::json
    );
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

Conclusion

This LocalStack Pro bug creates confusing behavior where Aurora PostgreSQL extensions appear to install successfully but actually split their components across multiple databases. While not a showstopper, it can cause significant debugging frustration for development teams.

Key takeaways:

• Always install Aurora PostgreSQL extensions in the cluster's primary database when using LocalStack Pro
• Verify extension installation with \dx command before proceeding with integration code
• Consider this a temporary workaround until LocalStack addresses the bug
• For critical integration testing, consider using real AWS Aurora to avoid this issue

Next steps:

• Report this bug to LocalStack Pro Support if you encounter it
• Update your team's development documentation to include the workaround
• Monitor LocalStack release notes for when this issue is resolved

---

Aaron Rose is software engineer and technology writer at tech-reader.blog.