โครงการ BI ของสตาร์ทอัพส่วนใหญ่มักเริ่มต้นเร็วเกินไปและใหญ่เกินความจำเป็น
ผู้ก่อตั้งมักจะถามคำถามง่าย ๆ ว่า "ผู้ใช้จากช่องทางนี้กลับมาใช้งานหลังจากรันครั้งแรกหรือไม่?" คำตอบควรจะเป็นการ query ข้อมูล แต่บ่อยครั้งกลับกลายเป็นโครงการสร้างแพลตฟอร์ม: เชื่อมต่อทุกแหล่งข้อมูล สร้าง warehouse กำหนด event ทำความสะอาด identity สร้าง dashboard และรอ
งานเหล่านั้นสำคัญในที่สุด แต่สำหรับทีมเล็ก ๆ อาจไม่ใช่ก้าวแรกที่ถูกต้อง ฐานข้อมูลผลิตภัณฑ์รู้อยู่แล้วเกือบทุกอย่างที่ผู้ก่อตั้งต้องการรู้ มันรู้ว่าใครสมัครใช้งาน ใครรันอะไร ใช้อะไรไปเท่าไร มีค่าใช้จ่ายเท่าไร อะไรล้มเหลว และพวกเขากลับมาหรือไม่
ปัญหาที่แท้จริงไม่ใช่ว่าความจริงอยู่ที่ไหน แต่คือจะให้นายหน้า AI วิเคราะห์ความจริงนั้นได้อย่างไรโดยไม่เปิดเผยฐานข้อมูล production ต้นฉบับ
นี่คือรูปแบบที่เราใช้ที่ VM0: สาขา Neon ที่ถูกปกปิดข้อมูลและเปิดให้อ่านอย่างเดียว ซึ่งให้นายหน้า AI ของเราเข้าถึงข้อมูลที่เพียงพอสำหรับการรัน BI โดยไม่เปิดเผยข้อมูลที่ไม่ควรเห็น
ปัญหาของผู้ก่อตั้ง: คำถามมาก่อนทีม data
บริษัทระยะเริ่มต้นไม่ได้ขาดคำถาม แต่ขาดเวลา
ทุกวัน ทีมผู้ก่อตั้งอยากรู้เรื่องเหล่านี้ เช่น:
- ทราฟฟิกเมื่อวานกลายเป็นผู้ใช้จริงหรือไม่?
- ช่องทางสมัครใช้งานไหนที่สร้างผู้ใช้ที่รันงานจริง?
- ผู้ใช้ที่รันครั้งแรกกลับมาหลังจาก 7 หรือ 30 วันหรือไม่?
- บัญชีแบบชำระเงินไหนเริ่มเงียบ?
- route ของโมเดลไหนที่ทำให้ต้นทุนสูง?
- มีผู้ใช้ทดลองที่ใช้ compute มากก่อนจะเปลี่ยนเป็นลูกค้าจริงหรือไม่?
- สุขภาพของผลิตภัณฑ์ดีขึ้นหรือแย่ลงตั้งแต่เมื่อวาน?
คำถามเหล่านี้ไม่ใช่เรื่องแปลกใหม่ แต่เป็นจังหวะการดำเนินงานของสตาร์ทอัพ
แต่การตอบคำถามเหล่านี้ด้วยแนวทาง BI แบบเดิมสร้างภาระงานมาก โดยปกติคุณจะเริ่มจากการย้ายข้อมูลออกจากฐานข้อมูลผลิตภัณฑ์ไปยังระบบอื่น จากนั้น normalize ข้อมูล กำหนด metric สร้างความสัมพันธ์ใหม่ และตั้งค่า dashboard ทีมจะได้ stack analytics ที่สะอาดขึ้น แต่ผู้ก่อตั้งมักต้องรอหลายวันหรือหลายสัปดาห์กว่าจะได้คำตอบที่ควรเริ่มต้นจาก SQL query ง่าย ๆ
สำหรับสตาร์ทอัพเล็ก ๆ การแลกเปลี่ยนแบบนี้อาจไม่คุ้มค่า คุณไม่จำเป็นต้องมี data platform ที่สมบูรณ์เพื่อถามคำถามการดำเนินงาน 20 ข้อแรก คุณแค่ต้องมีวิธีที่ปลอดภัยในการ query แหล่งข้อมูลจริงที่คุณมีอยู่แล้ว
ฐานข้อมูลคือแหล่งข้อมูลจริงอยู่แล้ว
ที่ VM0 ฐานข้อมูลผลิตภัณฑ์มีข้อเท็จจริงที่สำคัญต่อการตัดสินใจระดับผู้ก่อตั้งหลายประการ:
- องค์กรและผู้ใช้
- สถานะการสมัครและการต่ออายุ
- การรันและตารางเวลาของ AI agent
- การใช้และการบริโภคเครดิต
- โมเดลที่เลือกและ route ของผู้ให้บริการ
- สถานะของ connector
- สถานะความล้มเหลวและเวลาที่เกิดเหตุการณ์
ความสัมพันธ์เหล่านี้มีอยู่แล้ว และสดใหม่กว่าข้อมูลใน dashboard ใด ๆ และสะท้อนการทำงานจริงของผลิตภัณฑ์
เรื่องนี้สำคัญเพราะคำถาม BI ระยะแรกหลายข้อเป็นเรื่องความสัมพันธ์ ผู้ก่อตั้งไม่ได้อยากรู้แค่ page view หรือจำนวน run แต่ต้องการเชื่อมโยงพฤติกรรมข้ามระบบ:
จากผู้ใช้ที่สมัครจากช่องทางนี้ มีกี่คนที่รันงานในวันแรก และมีกี่คนที่กลับมาหลังจากรันครั้งแรก?
หรือ:
องค์กรที่ชำระเงินองค์กรใดบ้างที่ไม่ได้รันงานใน 7 วันที่ผ่านมา และก่อนหน้านี้พวกเขาดู active หรือไม่?
หรือ:
บัญชีทดลองใหม่ใช้ compute ไปเท่าไรใน 6 ชั่วโมงแรก ก่อนและหลังเราปรับ patrol ป้องกันการใช้ผิดวัตถุประสงค์?
คำถามเหล่านี้เหมาะกับฐานข้อมูลผลิตภัณฑ์โดยตรง แต่จะยากขึ้นมากหากทุกคำตอบต้องเริ่มจากการย้ายข้อมูลไปยังแพลตฟอร์มแยก
ทางลัดที่ไม่ปลอดภัยคือการเข้าถึง production ตรง ๆ
ทางลัดที่น่าดึงดูดใจคือ: ให้นายหน้า AI query production ได้เลย
แต่นั่นไม่สามารถยอมรับได้
ฐานข้อมูล production อาจมีข้อมูลที่อ่อนไหวที่สุดของบริษัท: อีเมล, prompt, เนื้อหาการแชท, ข้อมูลรับรอง, สถานะผู้ให้บริการที่เข้ารหัส, log, ข้อความ error, API key และบันทึกปฏิบัติการภายใน แม้นายหน้า AI จะระวัง แต่การเข้าถึงข้อมูลดิบก็สร้างปัญหาเรื่องขอบเขต นายหน้า AI อาจเห็นข้อมูลมากเกินไป ความผิดพลาดใน query, รายงาน หรือ screenshot อาจทำให้ข้อมูลรั่วไหลโดยไม่ตั้งใจ
การเขียนข้อมูลยิ่งแย่กว่า BI ไม่ควรเปลี่ยนแปลง production ได้ นักวิเคราะห์ ไม่ว่าจะเป็นมนุษย์หรือ AI agent ไม่ควรมีโอกาสเปลี่ยนข้อมูลผู้ใช้ด้วยคำสั่งผิดเพียงครั้งเดียว
ดังนั้นคำถามไม่ใช่ว่านายหน้า AI เขียน SQL ได้หรือไม่—พวกเขาทำได้ คำถามคือคุณจะให้นายหน้า AI เข้าถึงความจริงได้มากพอที่จะเป็นประโยชน์ ขณะเดียวกันก็รักษาความเป็นส่วนตัวและความปลอดภัยอย่างเข้มงวดได้หรือไม่
สำหรับเรา ข้อจำกัดเหล่านี้คือหัวใจสำคัญ:
- นายหน้า AI ไม่ควรเห็น prompt ดิบ
- นายหน้า AI ไม่ควรเห็นอีเมลดิบ
- นายหน้า AI ไม่ควรเห็นข้อมูลรับรองหรือความลับ
- นายหน้า AI ไม่ควรเห็น log ข้อความอ่อนไหว
- นายหน้า AI ไม่ควรมีสิทธิ์เขียนข้อมูลในแหล่ง BI
- ทีมผู้ก่อตั้งยังควรถามคำถามการดำเนินงานได้อย่างรวดเร็ว
นี่คือรูปแบบของระบบที่เราต้องการ
ทางสายกลางที่ปลอดภัย: ฐานข้อมูลที่ปกปิดข้อมูลและอ่านได้อย่างเดียว
Neon ทำให้รูปแบบนี้เป็นไปได้ เพราะ branch คือสำเนาของฐานข้อมูล Postgres ที่แยกและราคาถูก คุณสามารถสร้าง branch ที่เหมือน production, แปลงข้อมูล และเปิดเผย branch นั้นแทน production จริง
ที่ VM0 เราใช้วิธีนี้สร้างสิ่งที่เราเรียกว่า MaskDB
ขั้นตอนมีดังนี้:
- เริ่มจาก Neon parent branch ของ production
- สร้าง branch ใหม่ตามกำหนดเวลา
- ติดตั้ง PostgreSQL Anonymizer และตัวช่วย masking เฉพาะของ VM0
- กำหนด security label ให้กับ column ที่อ่อนไหว
- รันการปกปิดข้อมูลแบบ static บน branch
- ปรับ masking เฉพาะสำหรับ field ที่ต้องการการจัดการพิเศษ
- สร้าง role
masked_readonlyที่มีสิทธิ์SELECT - ให้นายหน้า AI query ด้วย role นั้น ไม่ใช่ production
จุดสำคัญคือการ masking เป็นแบบ static ค่าที่อ่อนไหวจะถูกเขียนทับบน branch ที่ปกปิดข้อมูลก่อนที่นายหน้า AI จะเชื่อมต่อ ต่างจากการให้ query ทุกครั้ง downstream ต้องจำว่าห้าม select อะไร ตัว branch เองคือขอบเขต
ใน MaskDB ของเรา ข้อมูลรับรองและความลับจะถูกปกปิด อีเมลและเบอร์โทรจะถูก mask บางส่วน เนื้อหาผู้ใช้ เช่น prompt, ข้อความแชท, schedule prompt และผลลัพธ์ของ agent จะถูกลบ ข้อความ error จะถูกลดเหลือแค่ประเภท ไม่ใช่ stack หรือข้อความเต็ม ตารางที่ไม่ควรใช้ในการวิเคราะห์จะถูกลบออกทั้งหมด
ขณะเดียวกัน ตัวระบุที่ไม่เปิดเผยตัวตน เช่น org_id, user_id และ clerk_user_id จะยังสามารถ join ได้ นี่คือสิ่งที่ทำให้ BI เป็นไปได้ เราไม่ต้องการให้นายหน้า AI รู้ที่อยู่อีเมลหรือข้อความ prompt ของบุคคล แต่ต้องรู้ว่าองค์กรเดียวกันสมัครใช้งาน รันงาน ใช้เครดิต สมัครสมาชิก หยุดใช้งาน หรือกลับมาใหม่
นี่คือจุดสมดุล: ปกปิดข้อมูลที่อ่านออกและอ่อนไหว แต่รักษาโครงสร้างความสัมพันธ์ไว้
นายหน้า AI ทำอะไรได้เมื่อมีขอบเขตนี้
เมื่อมีฐานข้อมูลที่ปกปิดข้อมูลและอ่านได้อย่างเดียว นายหน้า AI จะเริ่มมีประโยชน์อย่างรวดเร็ว
สามารถถามคำถามกับข้อมูลผลิตภัณฑ์โดยตรง เช่น:
- การรักษาผู้ใช้ใน 7 และ 30 วัน
- การเปลี่ยนจากสมัครเป็นรันแรก
- การรักษาผู้ใช้หลังรันแรก
- การหยุดใช้งานขององค์กรที่ชำระเงิน
- สถานะการสมัครและการจับตาการยกเลิก
- การใช้โมเดลตามโมเดลที่เลือก
- route ของผู้ให้บริการที่ติดตั้งกับที่ผู้ใช้เลือกเอง
- การใช้ compute ในช่วงทดลอง
- ต้นทุนต่อ run ตามโมเดล
- อัตราความล้มเหลวและอัตราสำเร็จตาม cohort
ยังสามารถผสมข้อมูลจริงจากฐานข้อมูลกับระบบรอบข้างได้ด้วย
Morning Brief ของเราดึงข้อมูลจาก Plausible, Axiom, Sentry, Google Ads, GitHub และแหล่งปฏิบัติการอื่น ๆ ฐานข้อมูลบอกเราว่าผู้ใช้และองค์กรทำอะไร Plausible บอกว่าเกิดอะไรขึ้นบนเว็บไซต์ PostHog ช่วยให้บริบท event ของผลิตภัณฑ์ Axiom บอกว่าเกิดอะไรขึ้นใน log และ request path Sentry จับ error Stripe และ Clerk ช่วยอธิบายเรื่อง billing และ identity GitHub แสดงประสิทธิภาพงานวิศวกรรม
ประเด็นไม่ใช่การแทนที่ทุกเครื่องมือด้วย SQL แต่คือต้องการให้นายหน้า AI เชื่อมโยงข้อเท็จจริงที่ผู้ก่อตั้งสนใจจริง ๆ
ตัวอย่างเช่น:
Google แบบชำระเงินส่งทราฟฟิกมากกว่า organic เมื่อวานนี้ ผู้ใช้เหล่านั้นไปถึงการรันครั้งแรกจริงหรือหยุดที่ต้น funnel?
หรือ:
เราเปลี่ยน patrol ป้องกันการใช้ผิดวัตถุประสงค์ในช่วงทดลอง บัญชีทดลองใหม่ใช้ compute น้อยลงในชั่วโมงแรกหรือไม่?
หรือ:
route ของโมเดลนี้ถูกกว่าต่อ run เรื่องนี้ปรากฏในประวัติการใช้งานแชทจริงหรือแค่ในทฤษฎีราคา?
เหล่านี้ไม่ใช่คำถาม dashboard แต่เป็นคำถามการดำเนินงาน เปลี่ยนไปตามสัปดาห์หรือวัน นายหน้า AI ที่เข้าถึงฐานข้อมูลอย่างปลอดภัยสามารถตอบได้โดยไม่ต้องขอวิศวกรสร้าง view ใหม่ทุกครั้ง
ตัวอย่างจริง: การรักษาผู้ใช้และสุขภาพผู้ใช้นอกองค์กร
หนึ่งในรายงานภายในประจำวันที่เราดูคือสุขภาพผู้ใช้นอกองค์กรในช่วง 24 ชั่วโมงล่าสุด
รายงานเริ่มจาก MaskDB แล้วใช้ชุด exclusion อย่างเข้มงวด ตัดองค์กร VM0 ภายในออก ตัดองค์กรที่ถูก Clerk แบนหรือล็อกว่าเป็น spam ออก ชุด exclusion เดียวกันนี้ใช้กับทุกที่ รวมถึงจำนวนการสมัครและ cohort retention เพื่อให้ตัวหารตรวจสอบย้อนกลับได้
จากนั้นนายหน้า AI สามารถสร้างรายงานการดำเนินงานที่กระชับได้:
- จำนวน run และองค์กรภายนอกที่ active
- อัตราสำเร็จ
- สัดส่วน trigger ระหว่าง web, CLI, schedule และ route ที่ไม่ใช่ Zero
- สัดส่วนโมเดล
- โหมดผู้ให้บริการ
- กิจกรรมขององค์กรที่ชำระเงิน
- องค์กรที่ชำระเงินแต่หยุดใช้งาน
- การสมัครใหม่แบบชำระเงินและองค์กรที่อยู่ในช่วงทดลอง
- การจับตาการยกเลิก
- การแบ่งกลุ่มผู้ใช้ใน 30 วัน
- การรักษาผู้ใช้จากสมัครถึง run
- การรักษาผู้ใช้หลังรันแรก
นี่คือรายงานที่ทีมผู้ก่อตั้งต้องการ ไม่ต้องใช้ prompt ดิบ ไม่ต้องใช้อีเมลดิบ ไม่ต้องเข้าถึง production แบบเขียนได้
แต่ต้องสามารถ join ข้อเท็จจริงของผลิตภัณฑ์ได้อย่างถูกต้อง
ในการรันครั้งหนึ่ง นายหน้า AI พบว่าองค์กรนอกองค์กรที่ active เพียงไม่กี่แห่งสร้างปริมาณงานส่วนใหญ่ หลายองค์กรที่ชำระเงินหยุดใช้งาน และ cohort การสมัครล่าสุดมีอัตรา activation ต่ำอย่างชัดเจนซึ่งน่าจะเกิดจาก spam registration ที่ทำให้ตัวหารสูงเกินจริง เหล่านี้คือสิ่งที่ผู้ก่อตั้งควรเห็นได้เร็ว ไม่ใช่รอหลายสัปดาห์ใน dashboard
ตัวอย่างที่สอง: เศรษฐศาสตร์ของการใช้ผิดวัตถุประสงค์ในช่วงทดลอง
ข้อมูลผลิตภัณฑ์ที่ปกปิดข้อมูลยังมีประโยชน์กับคำถามที่ไม่ใช่กราฟ BI แบบคลาสสิก
ตอนที่เราดูปัญหาการใช้ผิดวัตถุประสงค์ในช่วงทดลอง metric ที่มีประโยชน์ไม่ใช่ compute ที่ใช้รวม เพราะจะเอนเอียงไปทางบัญชีเก่าที่มีเวลามากกว่าในการใช้เครดิต คำถามที่ดีกว่าคือ:
บัญชีใหม่ใช้ compute ในช่วงทดลองไปเท่าไรในชั่วโมงแรกหลังสมัคร?
โดยใช้ MaskDB นายหน้า AI วัดการใช้ compute ในช่วงเวลาหลังสมัคร โดยใช้ข้อมูลการใช้เครดิตจาก event, เวลาสมัครจาก metadata ขององค์กร และสถานะการสมัครเพื่อแยกเศรษฐศาสตร์ของช่วงทดลองออกจากการใช้งานแบบชำระเงิน
หลังจาก patrol เริ่มใช้งาน การใช้ compute ในช่วงทดลองเฉลี่ยในชั่วโมงแรกหลังสมัครลดลงมากกว่า 80% ส่วนกลุ่มที่ใช้หนักเกือบหายไป ที่เปอร์เซ็นไทล์ 90 การใช้ compute ในชั่วโมงแรกของช่วงทดลองลดจากประมาณ $4.05 เหลือประมาณ $0.26 ลดลง 94%
ตัวเลขนี้ไม่ใช่แค่จุดข้อมูล analytics แต่มันเปลี่ยนมุมมองการดำเนินงานของธุรกิจ มันบอกทีมผู้ก่อตั้งว่าไม่เพียงแต่การใช้ผิดวัตถุประสงค์ถูกตรวจจับ แต่เศรษฐศาสตร์ของช่วงทดลองก็กำลังไปในทิศทางที่ถูกต้อง
และสิ่งนี้เป็นไปได้เพราะฐานข้อมูลมีความจริง ขณะที่ branch ที่ปกปิดข้อมูลทำให้ปลอดภัยสำหรับนายหน้า AI ในการวิเคราะห์
ตัวอย่างที่สาม: ต้นทุนโมเดลในผลิตภัณฑ์จริง
หน้าราคากับเอกสาร benchmark มีประโยชน์ แต่ไม่ตอบคำถามที่ผู้ก่อตั้งอยากรู้จริง ๆ ว่า:
โมเดลนี้มีต้นทุนเท่าไรในผลิตภัณฑ์จริงของเรา จากการรันจริง?
โดยใช้ MaskDB นายหน้า AI เปรียบเทียบการรันแชทในอดีตโดย join ข้อมูลการรันกับโมเดลที่เลือกขณะรัน และรวมเครดิตที่ถูกคิดค่าจาก event การใช้งาน
ความแตกต่างนี้สำคัญ คุณไม่ควรอ้างอิงการรันในอดีตด้วยผู้ให้บริการโมเดลปัจจุบันของผู้ใช้ เพราะ default เปลี่ยนได้ โมเดลที่เลือกขณะรันคือแหล่งข้อมูลจริง
จากการวิเคราะห์ของเรา DS v4 Pro มีต้นทุนเครดิตต่อการรันแชทแบบ median ประมาณ 49% ของ Sonnet หรือพูดอีกแบบ median ของการรันแชทจริงถูกกว่าประมาณ 51% บน route นั้น
นี่คือ BI ระดับผู้ก่อตั้ง เชื่อมโยงพฤติกรรมผลิตภัณฑ์ ต้นทุนโครงสร้างพื้นฐาน และกลยุทธ์โมเดล โดยไม่ต้องมี warehouse ใหม่ แค่ต้องเข้าถึงข้อมูล relational ที่ถูกต้องอย่างปลอดภัย
นี่ไม่ใช่การแทน warehouse ตลอดไป
ถึงจุดหนึ่งบริษัทจะต้องมี data stack ที่เป็นทางการมากขึ้น
เมื่อ metric ต้องการการกำกับดูแลเชิงความหมายที่เข้มงวด หลายทีมต้องใช้คำนิยามเดียวกัน การเติมข้อมูลย้อนหลังซับซ้อน หรือ dashboard กลายเป็นส่วนหนึ่งของระบบปฏิบัติการ warehouse หรือ lakehouse อาจเป็นคำตอบที่ถูกต้อง
แต่สตาร์ทอัพจำนวนมากรีบไปหาคำตอบนั้นเร็วเกินไป
ถ้าคุณเป็นทีมผู้ก่อตั้งเล็ก ๆ ระบบ BI แรกควรช่วยให้คุณตอบคำถาม ไม่ใช่สร้างผลิตภัณฑ์ที่สองให้ต้องดูแล ฐานข้อมูลที่ปกปิดข้อมูลอาจเป็นสะพาน ไม่ได้แปลว่าการทำ data modeling ไม่สำคัญ แต่คือการตระหนักว่าฐานข้อมูลผลิตภัณฑ์มีความสัมพันธ์ที่คุณต้องใช้ในการตัดสินใจชุดถัดไปอยู่แล้ว
นายหน้า AI ไม่ได้แทนที่การใช้วิจารณญาณ แต่มันทำให้เวอร์ชันแรกของการวิเคราะห์มีต้นทุนต่ำลง
รูปแบบสำหรับทีมผู้ก่อตั้ง
รูปแบบนี้เรียบง่าย:
- ถือว่าฐานข้อมูลผลิตภัณฑ์คือแหล่งข้อมูลจริงแรกสุด
- อย่าเปิดเผย production ดิบให้นายหน้า AI
- ใช้ branch ที่เหมือน production ไม่ใช่ชุดข้อมูลตัวอย่างที่สร้างเอง
- ปกปิด column ที่อ่อนไหวแบบ static ก่อนเข้าถึง
- รักษาตัวระบุ join ที่ไม่เปิดเผยตัวตนเพื่อให้วิเคราะห์ได้
- เปิด branch ผ่าน role ที่อ่านได้อย่างเดียว
- ให้นายหน้า AI รันวงจรวิเคราะห์ข้าม MaskDB และเครื่องมือรอบข้าง
สิ่งนี้ให้ทีมผู้ก่อตั้งมีระบบปฏิบัติการที่ใช้งานได้จริงโดยไม่ต้องสร้าง data platform เต็มรูปแบบก่อน
ยังสร้างท่าทีด้านความปลอดภัยที่สะอาดขึ้น นายหน้า AI มีขอบเขตที่ชัดเจน ฐานข้อมูลที่เห็นถูกแปลงแล้ว role ที่ใช้เขียนไม่ได้ รายงานที่สร้างสามารถจำกัดให้ใช้ตัวระบุแบบ hash หรือแบบรวม
นี่คือสมดุลที่เราต้องการที่ VM0: ความเป็นส่วนตัวและความปลอดภัยเป็นพื้นฐาน ไม่ใช่สิ่งที่ต้องแลกเปลี่ยน ขณะเดียวกันก็ให้ทีมผู้ก่อตั้งเข้าใจธุรกิจได้เร็วขึ้นมาก
ก่อนจะสร้าง data lake ลองถามว่าการมี branch ที่ปกปิดข้อมูลและอ่านได้อย่างเดียวของฐานข้อมูลผลิตภัณฑ์ของคุณ ตอบคำถาม 20 ข้อต่อไปที่ทีมคุณมีได้หรือไม่
สำหรับเรา นี่คือเส้นทางสู่ BI ที่เร็วกว่า
แหล่งอ้างอิง
- Neon, "Create Environments with Masked Production Data Using Neon Branches": https://neon.com/blog/environments-masked-production-data
- Neon fork ของ PostgreSQL Anonymizer: https://github.com/neondatabase/postgresql_anonymizer
