Forem: DDLTODATA

How My First Hacker News Launch Went (And What I Did About It)

DDLTODATA — Sun, 11 Jan 2026 22:05:53 +0000

The product: DDL to Data, a tool that generates realistic test data from SQL schemas. No more copying production data or maintaining brittle seed scripts.

The Launch

Submitted a Show HN post on a Tueday morning. Within an hour, I noticed something was wrong, I could see my post when logged in, but it was invisible in incognito mode and on mobile. The post had been soft-killed, likely because my account was new and my username matched my product name.

I emailed the HN mods (hn@ycombinator.com), explained the situation honestly, and asked them to review it. They restored it within a few hours.

The Results

Once live, the post climbed to #8 on the front page. Over the next 24 hours:

~1,000 visitors
425 people tried the demo
382 completed it (90% completion rate)
3 signups
0 purchases

What Went Wrong

The demo worked. People were interested. But almost nobody converted. Looking at the numbers, the problem was clear, people tried it, saw it worked, and left. The pricing was too high, the free tier was too limited, and the landing page was too wordy.

I also posted on r/SideProject and got torn apart. "Nobody will use this." "It sucks." No actionable feedback, just negativity. Meanwhile, someone shared the link in a Microsoft Teams chat and a VC reached out (turned out to be potentially sketchy, but still, signals of interest).

What I Changed

I took every piece of real feedback and rebuilt:

Better CTA, clearer path from demo to signup
Added the most requested feature, Story Mode, AI-generated coherent data
Lowered the prices, aligned with what competitors charge
Increased the limits, free tier now actually useful
Shortened the copy, less explaining, more showing

What I Learned

HN mods are reasonable, if your post gets killed, email them politely
High demo completion + low signup = conversion problem, not product problem
Reddit negativity without specifics isn't feedback
1,000 visitors means nothing if your funnel is broken
Launch is just the beginning, iteration is the actual work

What's Next

Relaunching on Product Hunt, continuing to write about the problem, and talking to anyone who will listen. The product is better now. Time to see if the market agrees.

Want to try it? Generate test data from your SQL schema →

How I Automated Database Seeding in CI/CD with One API Call

DDLTODATA — Sun, 11 Jan 2026 02:34:39 +0000

Automate PostgreSQL test data generation in your CI/CD pipeline. No more flaky tests from inconsistent data.

Manual test data generation doesn't scale. When you're running hundreds of CI builds per day, you need data generation that's fast, consistent, and fully automated.

DDL to Data provides a REST API that generates realistic PostgreSQL test data in milliseconds — fast enough for every pipeline run.

Quick Start

1. Get Your API Key

2. Save Your Schema

curl -X POST https://api.ddltodata.com/schemas \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY" \
  -d '{
    "name": "users",
    "ddl": "CREATE TABLE users (id SERIAL PRIMARY KEY, first_name VARCHAR(50), last_name VARCHAR(50), email VARCHAR(100) UNIQUE, created_at TIMESTAMP DEFAULT NOW());"
  }'

3. Generate Data

curl https://api.ddltodata.com/generate/users?rows=100 \
  -H "X-API-Key: YOUR_API_KEY"

Response:

[
  {
    "id": 1,
    "first_name": "Sarah",
    "last_name": "Chen",
    "email": "sarah.chen@techstartup.io",
    "created_at": "2024-03-15T09:23:41"
  },
  ...
]

That's it. Three lines to generate 100 rows of realistic test data.

API Reference

Base URL

https://api.ddltodata.com

Authentication

All requests require an API key in the header:

X-API-Key: YOUR_API_KEY

Endpoints

Save Schema

POST /schemas

{
  "name": "products",
  "ddl": "CREATE TABLE products (id SERIAL PRIMARY KEY, name VARCHAR(100), price DECIMAL(10,2));"
}

Generate Data

GET /generate/{schema_name}?rows={count}&format={format}

Parameters:

rows — Number of rows (default: 10, max: 10,000)
format — Output format: json, csv, or sql

Generate Related Data

For multi-table schemas with foreign keys:

POST /generate/related?format={format}

{
  "tables": {
    "users": 10,
    "orders": 50,
    "order_items": 200
  }
}

Returns data for all tables with referential integrity maintained.

List Schemas

GET /schemas

Delete Schema

DELETE /schemas/{schema_name}

CI/CD Integration

GitHub Actions

name: Test with Generated Data

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest

    services:
      postgres:
        image: postgres:15
        env:
          POSTGRES_PASSWORD: postgres
          POSTGRES_DB: test_db
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

    steps:
      - uses: actions/checkout@v4

      - name: Create tables
        run: psql -h localhost -U postgres -d test_db -f schema.sql
        env:
          PGPASSWORD: postgres

      - name: Seed test data
        run: |
          curl -s "https://api.ddltodata.com/generate/users?rows=100&format=sql" \
            -H "X-API-Key: ${{ secrets.DDL_API_KEY }}" | \
            psql -h localhost -U postgres -d test_db
        env:
          PGPASSWORD: postgres

      - name: Run tests
        run: npm test

CircleCI

version: 2.1

jobs:
  test:
    docker:
      - image: cimg/node:18.0
      - image: cimg/postgres:15.0
        environment:
          POSTGRES_USER: postgres
          POSTGRES_DB: test_db
          POSTGRES_PASSWORD: postgres

    steps:
      - checkout

      - run:
          name: Wait for Postgres
          command: dockerize -wait tcp://localhost:5432 -timeout 1m

      - run:
          name: Create tables
          command: psql -h localhost -U postgres -d test_db -f schema.sql

      - run:
          name: Seed test data
          command: |
            curl -s "https://api.ddltodata.com/generate/users?rows=100&format=sql" \
              -H "X-API-Key: ${DDL_API_KEY}" | \
              psql -h localhost -U postgres -d test_db

      - run:
          name: Run tests
          command: npm test

GitLab CI

test:
  image: node:18
  services:
    - postgres:15
  variables:
    POSTGRES_DB: test_db
    POSTGRES_USER: postgres
    POSTGRES_PASSWORD: postgres
  script:
    - apt-get update && apt-get install -y postgresql-client curl
    - psql -h postgres -U postgres -d test_db -f schema.sql
    - |
      curl -s "https://api.ddltodata.com/generate/users?rows=100&format=sql" \
        -H "X-API-Key: ${DDL_API_KEY}" | \
        psql -h postgres -U postgres -d test_db
    - npm test

Jenkins

pipeline {
    agent any

    environment {
        DDL_API_KEY = credentials('ddl-api-key')
    }

    stages {
        stage('Seed Database') {
            steps {
                sh '''
                    curl -s "https://api.ddltodata.com/generate/users?rows=100&format=sql" \
                      -H "X-API-Key: ${DDL_API_KEY}" | \
                      psql -h localhost -U postgres -d test_db
                '''
            }
        }

        stage('Test') {
            steps {
                sh 'npm test'
            }
        }
    }
}

Language Examples

Python

import requests

API_KEY = "your_api_key"
BASE_URL = "https://api.ddltodata.com"

headers = {"X-API-Key": API_KEY}

# Generate data
response = requests.get(
    f"{BASE_URL}/generate/users",
    params={"rows": 100, "format": "json"},
    headers=headers
)

users = response.json()
print(f"Generated {len(users)} users")

JavaScript/Node.js

const API_KEY = process.env.DDL_API_KEY;

async function generateTestData(schemaName, rows = 100) {
  const response = await fetch(
    `https://api.ddltodata.com/generate/${schemaName}?rows=${rows}`,
    {
      headers: { 'X-API-Key': API_KEY }
    }
  );
  return response.json();
}

const users = await generateTestData('users', 100);
console.log(`Generated ${users.length} users`);

Go

package main

import (
    "encoding/json"
    "fmt"
    "net/http"
    "os"
)

func generateTestData(schemaName string, rows int) ([]map[string]interface{}, error) {
    url := fmt.Sprintf("https://api.ddltodata.com/generate/%s?rows=%d", schemaName, rows)

    req, _ := http.NewRequest("GET", url, nil)
    req.Header.Set("X-API-Key", os.Getenv("DDL_API_KEY"))

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    var data []map[string]interface{}
    json.NewDecoder(resp.Body).Decode(&data)
    return data, nil
}

Ruby

require 'net/http'
require 'json'

API_KEY = ENV['DDL_API_KEY']

def generate_test_data(schema_name, rows: 100)
  uri = URI("https://api.ddltodata.com/generate/#{schema_name}?rows=#{rows}")

  req = Net::HTTP::Get.new(uri)
  req['X-API-Key'] = API_KEY

  res = Net::HTTP.start(uri.hostname, uri.port, use_ssl: true) do |http|
    http.request(req)
  end

  JSON.parse(res.body)
end

users = generate_test_data('users', rows: 100)
puts "Generated #{users.length} users"

Best Practices

Store API Key Securely

Never commit API keys to version control. Use environment variables or secrets management:

GitHub Actions: Repository secrets
CircleCI: Project environment variables
GitLab: CI/CD variables (masked)
Jenkins: Credentials plugin

Cache Schemas

Save schemas once, generate many times. Don't re-upload schemas on every pipeline run.

Use Appropriate Row Counts

Unit tests: 10-50 rows
Integration tests: 100-500 rows
Load tests: 1,000-10,000 rows

Handle Rate Limits

The API returns 429 Too Many Requests if you exceed limits. Implement exponential backoff:

import time
import requests

def generate_with_retry(schema_name, rows, max_retries=3):
    for attempt in range(max_retries):
        response = requests.get(
            f"https://api.ddltodata.com/generate/{schema_name}?rows={rows}",
            headers={"X-API-Key": API_KEY}
        )

        if response.status_code == 429:
            time.sleep(2 ** attempt)
            continue

        return response.json()

    raise Exception("Max retries exceeded")

Performance

Response time: Under 100ms for most requests
Throughput: Generate 10,000 rows in a single request
Uptime: 99.9% SLA on paid plans

Fast enough that data generation won't slow down your CI/CD pipeline.

Pricing

Free — 50,000 rows/month, $0
Developer — 250,000 rows/month, $9/mo
Team — 1,000,000 rows/month, $29/mo

View all plans →

Get Started

Get your API key: ddltodata.com/tiers
Save your schema: POST /schemas
Generate data: GET /generate/{schema}?rows=100
Integrate with CI/CD: Use examples above

Questions? Reach out at support@ddltodata.com or check the User Guide.

Generate PostgreSQL Test Data Without Code (Step-by-Step)

DDLTODATA — Sun, 11 Jan 2026 02:30:56 +0000

Need PostgreSQL test data fast? Here's how to generate it in under a minute — no coding required.

Whether you're preparing a demo, testing a feature, or onboarding to a new project, you need realistic data. But copying production data is a security nightmare, and writing Faker scripts takes time you don't have.

DDL to Data's visual dashboard generates realistic PostgreSQL test data instantly. Just paste your schema and download the results.

Step 1: Go to the Dashboard

Visit ddltodata.com and scroll to the interactive demo.

You'll see a code editor pre-filled with an example schema. You can use this to test, or paste your own.

Step 2: Paste Your PostgreSQL Schema

Replace the example with your CREATE TABLE statement:

CREATE TABLE products (
  id SERIAL PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  description TEXT,
  price DECIMAL(10,2),
  category VARCHAR(50),
  sku VARCHAR(20) UNIQUE,
  in_stock BOOLEAN DEFAULT true,
  created_at TIMESTAMP DEFAULT NOW()
);

The dashboard accepts standard PostgreSQL DDL syntax including:

Multiple CREATE TABLE statements
Foreign key relationships
Constraints (NOT NULL, UNIQUE, DEFAULT)
All common PostgreSQL data types

Step 3: Click "Generate Test Data"

Hit the generate button. In milliseconds, you'll see realistic data:

[
  {
    "id": 1,
    "name": "Wireless Bluetooth Headphones",
    "description": "Premium noise-canceling headphones with 30-hour battery life",
    "price": 149.99,
    "category": "Electronics",
    "sku": "WBH-2024-001",
    "in_stock": true,
    "created_at": "2024-03-15T09:23:41"
  },
  {
    "id": 2,
    "name": "Ergonomic Office Chair",
    "description": "Adjustable lumbar support with breathable mesh back",
    "price": 299.00,
    "category": "Furniture",
    "sku": "EOC-2024-042",
    "in_stock": true,
    "created_at": "2024-03-14T14:56:12"
  }
]

Notice how:

name contains realistic product names
description has plausible product descriptions
price is a reasonable decimal value
sku follows a realistic SKU format
category contains appropriate category names

All inferred automatically from column names.

Step 4: Choose Your Format

Use the format toggle to switch between:

JSON — For APIs, JavaScript, most modern apps
CSV — For spreadsheets, data imports, Excel
SQL — Ready-to-run INSERT statements for PostgreSQL

SQL Output Example

INSERT INTO products (id, name, description, price, category, sku, in_stock, created_at) VALUES
(1, 'Wireless Bluetooth Headphones', 'Premium noise-canceling headphones with 30-hour battery life', 149.99, 'Electronics', 'WBH-2024-001', true, '2024-03-15T09:23:41'),
(2, 'Ergonomic Office Chair', 'Adjustable lumbar support with breathable mesh back', 299.00, 'Furniture', 'EOC-2024-042', true, '2024-03-14T14:56:12');

Copy and paste directly into psql or your PostgreSQL client.

Step 5: Download or Copy

Copy — Click to copy to clipboard
Download — Save as a file

That's it. Realistic test data in under 60 seconds.

Working with Multiple Tables

The dashboard handles multi-table schemas with foreign keys:

CREATE TABLE categories (
  id SERIAL PRIMARY KEY,
  name VARCHAR(50) NOT NULL
);

CREATE TABLE products (
  id SERIAL PRIMARY KEY,
  category_id INTEGER REFERENCES categories(id),
  name VARCHAR(100) NOT NULL,
  price DECIMAL(10,2)
);

The generated data maintains referential integrity — every category_id in products will reference a valid id from categories.

Save Your Schemas (Optional)

Create a free account to:

Store schemas — Access them anytime without re-pasting
Generate more data — 50,000 rows/month free
Get an API key — For automation (see API guide)

Common Use Cases

Demo Preparation

Need to show a client realistic data? Generate it in seconds instead of sanitizing production data or hand-crafting fake records.

QA Testing

Fill your test database with varied, realistic data. Catch edge cases that test@test.com and John Doe would never reveal.

Developer Onboarding

New team members can seed their local database immediately without production access or waiting for data dumps.

Staging Environment Refresh

Repopulate staging with fresh data for each release cycle. No DevOps tickets, no data masking, no security review.

Tips for Better Results

Use Descriptive Column Names

The more descriptive your column names, the better the generated data:

Good column names → realistic data:

email → sarah.chen@company.io
phone_number → 555-234-5678
company_name → Nexus Industries

Vague column names → random strings:

e → xK9mP2qL
ph → 7nR4tY8w
cn → Lm3pQ6vX

Include Data Types

Explicit types help generate appropriate values:

-- Better
price DECIMAL(10,2)

-- Works but less precise
price VARCHAR(20)

Add Foreign Keys

Relationships ensure referential integrity:

-- Explicit relationship
user_id INTEGER REFERENCES users(id)

-- Also works (inferred from naming)
user_id INTEGER

What's Next?

Need automation? Check out the API integration guide for CI/CD pipelines
Want more rows? Create a free account for 50,000 rows/month
Have questions? Reach out at support@ddltodata.com

Generate your first dataset now at ddltodata.com — no signup required.

How to Generate Test Data for PostgreSQL (2 Methods)

DDLTODATA — Sun, 11 Jan 2026 02:27:39 +0000

Need realistic test data for your PostgreSQL database? Here are two approaches — pick the one that fits your workflow.

Generating test data for PostgreSQL shouldn't require copying production data or writing custom Faker scripts. Whether you need a quick dataset for a demo or automated data generation in your CI/CD pipeline, there's a faster way.

DDL to Data generates realistic test data directly from your PostgreSQL schema. Just paste your CREATE TABLE statements and get back JSON, CSV, or SQL INSERT statements instantly.

Two Ways to Generate PostgreSQL Test Data

1. Dashboard (No Code Required)

Best for: Quick demos, manual testing, non-technical users

Generate PostgreSQL Test Data — No Code Guide →

The visual dashboard lets you:

Paste your PostgreSQL DDL and get data immediately
Download as JSON, CSV, or SQL
Store schemas for reuse
No API key required for basic usage

Perfect when you need data now and don't want to write any code.

2. REST API (For Automation)

Best for: CI/CD pipelines, automated testing, developer workflows

PostgreSQL Test Data API for CI/CD →

The REST API enables:

Programmatic data generation
Integration with GitHub Actions, CircleCI, Jenkins
Database seeding in your test setup
Consistent, repeatable test data

Ideal for teams who want test data generation baked into their development workflow.

How It Works

DDL to Data reads your PostgreSQL schema and infers realistic values from column names:

CREATE TABLE customers (
  id SERIAL PRIMARY KEY,
  first_name VARCHAR(50),
  last_name VARCHAR(50),
  email VARCHAR(100) UNIQUE,
  phone VARCHAR(20),
  company_name VARCHAR(100),
  created_at TIMESTAMP DEFAULT NOW()
);

Automatically generates:

[
  {
    "id": 1,
    "first_name": "Sarah",
    "last_name": "Chen",
    "email": "sarah.chen@techcorp.io",
    "phone": "+1-555-234-5678",
    "company_name": "Nexus Industries",
    "created_at": "2024-03-15T09:23:41"
  },
  {
    "id": 2,
    "first_name": "Marcus",
    "last_name": "Johnson",
    "email": "m.johnson@startup.com",
    "phone": "+1-555-876-5432",
    "company_name": "Velocity Labs",
    "created_at": "2024-03-14T14:56:12"
  }
]

No configuration needed. Column names like email, phone, first_name, and company_name are automatically recognized and populated with appropriate data.

Why Not Just Use Production Data?

Copying production data into dev environments creates problems:

Security risk — PII in non-production environments
Compliance issues — GDPR, HIPAA, SOC 2 violations
DevOps overhead — VPC peering, access controls, data masking
Stale data — Production copies get outdated

DDL to Data generates production-shaped data without any of these concerns. The data looks real but isn't tied to real people.

Why Not Use Faker Directly?

Faker libraries work, but require:

Mapping every column to the right generator
Writing and maintaining seed scripts
Updating scripts when schemas change
Wiring up foreign key relationships manually

DDL to Data handles this automatically. Your schema already defines the structure — we just read it.

PostgreSQL-Specific Features

Data Type Support

Full support for PostgreSQL types:

SERIAL, BIGSERIAL, SMALLSERIAL
VARCHAR, TEXT, CHAR
INTEGER, BIGINT, SMALLINT
NUMERIC, DECIMAL, REAL, DOUBLE PRECISION
BOOLEAN
DATE, TIME, TIMESTAMP, TIMESTAMPTZ
UUID
JSON, JSONB

Foreign Key Relationships

Define relationships and get referentially-correct data:

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  customer_id INTEGER REFERENCES customers(id),
  total DECIMAL(10,2),
  status VARCHAR(20)
);

The generated customer_id values will match valid id values from the customers table.

Constraints Respected

NOT NULL — Always populated
UNIQUE — No duplicate values
CHECK — Constraints honored where possible

Get Started

Try the dashboard: ddltodata.com — paste your schema, get data

Use the API: Get your free API key — 50,000 rows/month free

Next: Learn the specific steps for no-code dashboard usage or API integration.

Why I Built DDL to Data

DDLTODATA — Sat, 03 Jan 2026 17:29:52 +0000

Production data doesn't belong in your dev environment. But getting realistic test data shouldn't be this hard.

I got tired of watching teams jump through hoops to get data into lower environments.

Copying production data into dev or staging? Security nightmare. But without realistic data, demos look fake and testing is worthless. There had to be a better way.

The Problem

Here's what I kept seeing:

Management needs a demo ready by Friday. Sales promised a client they'd see the product with "real" data. So someone suggests pulling from production.

Now DevOps is pissed. Security wants to know why we need VPC peering between prod and staging. Someone has to scramble to mask PII. A DBA gets pulled into a meeting. The "quick demo" becomes a two-week project involving three teams and four Slack channels.

All because we needed some realistic-looking data.

And it wasn't just demos. Every new developer onboarding needed a seeded database. Every QA cycle needed fresh test data. Every staging environment refresh became a production.

The answer was always the same: "Can we just copy prod?"

No. No you can't.

The Alternatives Sucked

Faker libraries? Great if you have time to wire up every column, write the boilerplate, and maintain the scripts. You need to map email to faker.email(), phone to faker.phone(), created_at to faker.date(). For every table. Every time the schema changes.

Nobody has that time when the demo is Thursday.

Prompt an LLM? Sure, it works. Until it formats things differently each time. Until your tests start flaking because the output structure shifted. Until you're paying tokens for every CI run and your pipeline depends on OpenAI's uptime.

Copy production data? Good luck getting that past security. And even if you do, now you're liable for customer PII sitting in your dev environment. One accidental log, one screenshot in a bug report, and you've got a compliance incident.

None of these options made sense for the simple ask: "I need realistic data that isn't production data."

The Realization

Then it hit me.

The schema already defines what the data should look like.

email VARCHAR(100) should be an email. phone VARCHAR(20) should be a phone number. created_at TIMESTAMP should be a timestamp. first_name VARCHAR(50) should be a first name.

The structure is right there in the DDL. Why were we fighting security, begging DevOps, and risking compliance just to get data that the schema could already describe?

I didn't need production data. I needed production-shaped data.

What I Built

DDL to Data takes your CREATE TABLE statement and generates realistic data instantly.

Paste your schema, get JSON back. Emails look like emails. Phone numbers look like phone numbers. Names look like names. All inferred from column names automatically.

No production access needed. No VPC peering. No PII concerns. No security review.

And it's not an LLM — it's deterministic pattern matching. Same schema, same structure, every time. Fast enough for CI/CD (milliseconds, not seconds), realistic enough for demos, consistent enough for tests.

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  first_name VARCHAR(50),
  last_name VARCHAR(50),
  email VARCHAR(100),
  phone VARCHAR(20),
  created_at TIMESTAMP
);

Becomes:

[
  {
    "id": 1,
    "first_name": "Sarah",
    "last_name": "Chen",
    "email": "sarah.chen@techstartup.io",
    "phone": "+1-555-234-5678",
    "created_at": "2024-03-15T09:23:41"
  },
  {
    "id": 2,
    "first_name": "Marcus",
    "last_name": "Johnson",
    "email": "m.johnson@company.com",
    "phone": "+1-555-876-5432",
    "created_at": "2024-03-14T14:56:12"
  }
]

No setup. No configuration. No prompts to engineer.

Who It's For

This is for:

Teams who need demo data without the security headache
Dev environments that shouldn't touch production
QA engineers who need realistic data, not test@test.com and John Doe everywhere
CI/CD pipelines that need consistent, fast data generation
Anyone who's been on a call where management asks "why can't we just copy prod?"

If you've ever spent more time getting test data than actually testing, this is for you.

What's Next

I'm building two features that extend this further:

Story Mode — Describe the scenario you want, and the data adapts to match. "A growing B2B SaaS with enterprise clients and some churned accounts" or "an e-commerce store with seasonal holiday trends." The data tells a coherent story instead of just being random values.

Direct Database Seeding — Skip the copy-paste. Connect DDL to Data directly to your PostgreSQL database and populate tables in one click. Seed staging without ever touching production.

Try It

If you've ever been stuck between "we need realistic data" and "we can't touch production," this is what I built it for.

Free tier. No credit card. Just paste your schema and see what comes out.

Try DDL to Data →

Built by Travis. Questions or feedback? Reach out at travis@ddltodata.com or @DDLTODATA on X.