Fly Postgres do Supabase quản lý
(supabase.com)- Hợp tác về Postgres được quản lý giữa Supabase và Fly.io là một nỗ lực nhằm đưa các tính năng cơ sở dữ liệu của Supabase lên hạ tầng Fly, nhưng hiện đã bị khai tử
- Dịch vụ này hướng tới cấu hình triển khai Postgres trong môi trường điện toán biên chạy tại hơn 37 địa điểm của Fly.io, giúp ứng dụng Fly và cơ sở dữ liệu nằm gần nhau hơn
- Phạm vi tính năng bao gồm hơn 40 extension, pgvector, Supavisor, sao lưu hằng ngày, khôi phục về một thời điểm cụ thể, branching, observability, migration, dashboard, cùng API tự động sinh REST·GraphQL
- Đợt triển khai ban đầu được tiến hành dần dần, và vẫn còn các công việc tích hợp giữa hai công ty như billing, chuyển giao hỗ trợ, đào tạo nội bộ, cũng như sửa lỗi từ những người thử nghiệm đầu tiên
- Trong khi Postgres hiện có của Fly là dịch vụ không được quản lý, nơi người dùng chịu trách nhiệm vận hành, Fly Postgres là dịch vụ được quản lý trong đó Supabase đảm nhiệm scaling, backup, replication và upgrade
Trạng thái ra mắt và phạm vi dịch vụ
- Fly Postgres hiện đã bị khai tử; có thể xem chi tiết trong thông báo khai tử
- Supabase và Fly.io đã ra mắt Fly Postgres như một dịch vụ Postgres được quản lý chạy trên hạ tầng Fly
- Cơ sở dữ liệu chạy trên nền tảng điện toán biên của Fly.io và có thể bắt đầu bằng cách chọn trong hơn 37 địa điểm của Fly.io
- Các ứng dụng nặng về dữ liệu được triển khai trên Fly có thể kỳ vọng độ trễ thấp hơn bằng cách đặt cơ sở dữ liệu trong cùng hạ tầng
Tính năng Supabase Managed Postgres
- Fly Postgres mang các tính năng chính thường kỳ vọng ở cơ sở dữ liệu được Supabase quản lý vào môi trường Fly
- Hơn 40 extension của Supabase Postgres
- Hỗ trợ workload Vector/AI dựa trên pgvector
- Supavisor, connection pooler cho Postgres của Supabase
- Sao lưu hằng ngày và khôi phục về một thời điểm cụ thể
- Branching, observability, migration
- Dashboard để quản trị cơ sở dữ liệu
- Data API tự động sinh
- REST API dùng PostgREST
- GraphQL API dùng pg_graphql
Rollout dần dần và thử nghiệm ban đầu
- Việc ra mắt được tiến hành theo hình thức rollout dần dần
- Tích hợp giữa hai công ty bao gồm các công việc như billing, chuyển giao hỗ trợ và đào tạo nhân viên Supabase
- Dịch vụ đang được kiểm chứng cùng một số tester ban đầu, và vẫn còn lỗi cần sửa
- Những người muốn tham gia thử nghiệm có thể đăng ký vào waitlist
- Kế hoạch là tiếp nhận thêm nhiều tester hơn vào tháng sau và chia sẻ lịch ra mắt bổ sung sau khi chắc chắn về độ an toàn dữ liệu
Khác biệt giữa Postgres được quản lý và không được quản lý
- Cách Fly cung cấp Postgres hiện tại là không được quản lý
- Người dùng phải tự xử lý scaling, backup về một thời điểm cụ thể, replication, nâng cấp phiên bản lớn, v.v.
- Với Postgres được quản lý của Fly do Supabase vận hành, người dùng có thể tập trung hơn vào việc xây dựng ứng dụng
- Dịch vụ được quản lý được tạo bằng Fly extension API
- API tương tự cũng được dùng cho Fly Redis
- Tester có thể tạo cơ sở dữ liệu Postgres bằng lệnh
fly extensionsfly extensions supabase create
- Khi dịch vụ ổn định, dự kiến sẽ được thay bằng namespace
postgresfly postgres create
Triển khai dựa trên Fly Machines
- Fly Postgres được xây dựng trên Fly machines
- Machines là Firecracker VM nhẹ, và Machines API cho phép kiểm soát chi tiết vòng đời ứng dụng
- Machines có thể bị dừng khi không hoạt động và được tiếp tục trong vài giây khi có yêu cầu mới
- Supabase đã tạo một wrapper TypeScript tên là fly-admin để đơn giản hóa tương tác với Fly API
- Vì Supabase đóng gói thêm một số dịch vụ cùng Postgres, họ chuẩn bị một Docker image duy nhất có thể truyền cho Fly Machines API
- Quy trình build hiện có dùng Packer để tạo AMI cho AWS, và Supabase tái sử dụng một phần pipeline này để build All In One Image
- All In One Image bao gồm mọi dịch vụ cần thiết để chạy một dự án Supabase trong một Docker container duy nhất
Chuyển sang multicloud
- Với lần ra mắt này, Supabase chính thức trở thành multicloud
- Supabase chủ ý tránh các dịch vụ được quản lý của AWS để đơn giản hóa việc chuyển sang multicloud
- Việc chuyển đổi không đơn giản vì các primitive cơ bản của mỗi nhà cung cấp cloud khác nhau đáng kể
- Fly Machines cung cấp cách dừng các VM không dùng đến và tiếp tục chúng một cách minh bạch trong vài giây
- Quy trình tạm dừng cơ sở dữ liệu không hoạt động trở nên đơn giản hơn
- AWS không có primitive để trực tiếp đạt được điều này
- Ngược lại, Fly thiếu một số primitive mà AWS cung cấp, nên cần giải pháp vòng tránh
- Fly Machines không có storage gắn qua mạng
- Supabase xem dữ liệu trên Fly volumes là dữ liệu tạm thời
- Supabase thực hiện backup vật lý bằng WAL-G cho mọi dự án chạy trên Fly
- Các thay đổi của cơ sở dữ liệu được stream liên tục lên S3
- Nếu host hoặc volume bị hỏng, dự án sẽ được khôi phục sang host Fly mới bằng dữ liệu S3 mới nhất
Quan sát vận hành và phân phối image
- Trên AWS, Supabase nhận AWS Health events để phát hiện sự cố host
- Trên Fly, log của Machine được gửi tới Logflare thông qua fly-log-shipper
- Supabase phát hành All In One image không chỉ lên registry container của AWS mà còn lên Fly Docker registry
- Việc phát hành lên Fly Docker registry cải thiện độ tin cậy và hiệu năng khi khởi chạy dự án trên Fly
Fly extension và tích hợp xác thực
- Fly cung cấp Extensions API để mở rộng nền tảng
- Supabase đã thêm một vài route vào API để provision người dùng và dự án
- Người dùng Fly có thể truy cập Supabase dashboard bằng thông tin đăng nhập Fly hiện có
- Supabase API khởi tạo luồng OAuth với Fly để xác thực người dùng
- Đội ngũ Supabase Auth đã tạo Fly OAuth provider để giúp việc tích hợp API dễ dàng hơn
Các vấn đề còn lại
- Supabase vẫn đang tiếp tục xử lý một số vấn đề vận hành cùng đội ngũ Fly
-
Hỗ trợ giới hạn mạng
- Tính năng giới hạn mạng chỉ hoạt động khi container nhận được đúng IP của client kết nối
- Trong cấu hình hiện tại, container thấy Fly proxy IP thay vì IP của client
- Kết nối đi qua Fly proxy, nơi expose Proxy protocol
- Postgres không thể trực tiếp dùng thông tin này, và Supabase đang xem xét cách để Supavisor nhận biết proxy-protocol
-
Backup nội bộ của Fly
- Fly hiện chưa cung cấp Blob storage được quản lý, nên backup dự án Fly được thực hiện lên AWS S3
- Cách này phát sinh chi phí băng thông giữa các cloud
- Fly đang phát triển Blob Storage
Cách bắt đầu và giá
- Có thể đăng ký preview qua preview form
- Khi tổ chức được thêm vào allowlist, có thể bắt đầu bằng Quickstart trong tài liệu
- Mỗi tổ chức Fly có thể nhận 1 dự án miễn phí
- Chi tiết billing vẫn đang được hoàn thiện, nhưng giá dự kiến sẽ không thay đổi đáng kể so với giá hiện tại của Supabase
1 bình luận
Ý kiến trên Hacker News
Tôi là CEO của Supabase. Fly Postgres hiện tại là không được quản lý, nên chúng tôi đang làm việc với Fly để vận hành một dịch vụ được quản lý
Mô hình này giống như những gì họ làm với đội ngũ Upstash cho Fly Redis: https://fly.io/docs/reference/redis/
Hiện chúng tôi vẫn đang triển khai các tính năng tính sẵn sàng cao cho nhóm tester, chưa có lịch cụ thể, nhưng sẽ phối hợp với đội Fly để đẩy nhanh nhất có thể
Tôi hiếm khi thấy trường hợp một công ty bên ngoài tham gia hợp tác để quản lý phiên bản được host của dịch vụ không tự host từ công ty khác
Trước đây tôi đã xem qua Supabase nhưng thấy hơi khó hiểu về cách tạo REST API cơ bản
Việc tạo bảng rồi tự động sinh API để tương tác nghe có vẻ hay, nhưng tôi không rõ nên đặt business logic ở đâu
Tôi cũng đã xem Edge Functions, nhưng các ví dụ lại giống xử lý tác vụ hơn nên không rõ có phải dùng cho mục đích đó không, cảm giác như tôi đang bỏ sót điều gì rất đơn giản
REST API khá tiện cho việc tổng hợp dữ liệu như join, nhưng đến lúc cần những thứ như transaction thì bắt đầu bị vướng
Bảo mật mức hàng (RLS) cho kiểm soát truy cập dựa trên vai trò cũng khá phiền, và trải nghiệm lập trình viên chưa thật sự tốt
Nếu yêu cầu DB đơn giản thì REST API rất tiện, nhưng nếu định làm thứ phức tạp hơn thì tốt hơn là học PL/pgSQL hoặc dùng kết nối DB thông thường
Phần lớn trường hợp thì lựa chọn 1 là đủ, còn 2 và 3 giống các công cụ bổ sung dùng khi cần hơn
Trong nhiều use case, logic có thể được đưa vào SQL stored procedure, và PostgreSQL cũng hỗ trợ stored procedure bằng JS hoặc Python
Tuy vậy, về trải nghiệm lập trình viên thì triển khai code logic dưới dạng container CI/CD thông thường hoặc function vẫn tốt hơn, và tùy bài toán chi phí mà cả hai cách đều được dùng khá nhiều
Supabase khuyến nghị Deno serverless function, nhưng với dự án web thì có lẽ đa số sẽ thích triển khai Node function lên Cloudflare hơn
Cuối cùng, có vẻ khách hàng mục tiêu là những người đặt 99% logic ở frontend JS, còn backend chỉ xử lý CRUD và xác thực
Với phần đó, chúng tôi đã xây một hệ thống sự kiện dựa trên Postgres WAL để xử lý kiểu callback system
Ban đầu chúng tôi cũng tạo một thư viện nhỏ cho Elixir, bắt đầu từ việc fork Supabase Realtime: https://github.com/cpursley/walex
Gần đây, chúng tôi còn thêm khả năng cấu hình để WalEx chuyển tiếp sự kiện sang webhook hoặc EventRelay, để không cần biết Elixir vẫn dùng được
Vì chúng tôi dùng Next.js nên khá nhiều lời gọi DB nằm trong các serverless function của Next
Tuy vậy, chúng tôi cũng định xem xét chuyển một phần logic sang Supabase function để đặt nó gần DB nhất có thể, dù hiện tại vẫn chưa muốn chuyển sang Deno
Khi truy cập Supabase từ server, bạn có thể dùng tính năng PostgREST mà Supabase client sử dụng, hoặc truy cập trực tiếp vào Postgres bằng thư viện
pgthông thườngTôi rất mong chờ chuyển sang cái này. Chúng tôi đã xây Booklet trên Fly.io và Fly Postgres với kiến trúc ứng dụng phân tán: https://www.contraption.co/essays/booklet-architecture/
Vấn đề lớn nhất là cấu hình Fly Postgres. Đặc biệt là việc Fly đặt HAProxy phía trước Postgres và áp giới hạn kết nối 30 phút, khiến kết nối liên tục bị cắt: https://community.fly.io/t/postgresql-connection-issues-have...
Đây đáng lẽ phải là vấn đề có thể quản lý được, nhưng hành vi đóng kết nối có những điểm kỳ lạ không khớp với tài liệu nên nó vẫn cứ thiếu ổn định
Tôi muốn biết liệu Postgres mới có tiếp tục đặt cùng HAProxy ở phía trước không
https://supabase.com/blog/supavisor-postgres-connection-pool...
https://postgrest.org/
Hôm nay tôi thấy cái này trong tài liệu Fly và tự hỏi không biết mình đã bỏ lỡ nó trên HN hay sao, hóa ra là mới ra
Ý nghĩ thứ hai của tôi là việc thanh bên có cả Postgres by Fly lẫn Postgres by Supabase trông khá kỳ
Không có phần so sánh nào nổi bật, nên nếu triển khai app trên Fly và cần Postgres thì khá khó hiểu là nên chọn cái nào
Cá nhân tôi, nếu cần DBMS trên Fly thì có lẽ tôi sẽ dùng distributed SQLite của LiteFS, còn nếu cần Postgres thì khác biệt giữa Fly và Supabase về cơ bản là không được quản lý so với được quản lý
Rất tuyệt. Tôi vốn không thích phần cài đặt hạn chế mạng của Supabase: https://supabase.com/docs/guides/platform/network-restrictio...
Tôi nhớ lần trước khi xem thì có một vấn đề kỳ quặc khi để lộ IP của ứng dụng Fly cho Supabase và khóa Supabase theo IP đó
Việc Supabase thực sự nằm bên trong mạng Fly là rất tuyệt
Điều này cũng có trong tài liệu mạng của Fly.io
Tôi nghe nói Supabase có vấn đề về khả năng mở rộng khi vượt qua giai đoạn nguyên mẫu, nên muốn hỏi liệu ai có kinh nghiệm production có thể chia sẻ không
Cụ thể bạn đang nói đến vấn đề nào?
Tôi là Joshua bên Fly.io. Nếu có câu hỏi về tích hợp này thì tôi sẽ trả lời
Tôi có dùng cho vài side project, nhưng chưa dùng cho dự án lớn nào
Điều tôi mong tiếp theo là lưu trữ Blob; tôi về cơ bản muốn dùng mọi thứ có trạng thái dưới dạng managed, nên rất vui khi nghe là việc đó cũng đang được tiến hành
Không biết đã có chi tiết nào về giá của dịch vụ Postgres mới này chưa
Hiện tại tôi đang chạy một DB lớn trên Fly và đang tìm PostgreSQL được quản lý, nên tin này là cực kỳ đáng mừng
Chúng tôi là một đội Elixir hoàn toàn, nên thời điểm này không thể tốt hơn
“Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral.”
Tôi chưa từng dùng AWS và cũng không hiểu rõ về lưu trữ gắn qua mạng, nên muốn biết chính xác Fly volume khác gì với loại lưu trữ gắn qua mạng của các nhà cung cấp khác
Nếu tạo một Fly volume rồi có thể chuyển nó sang máy chủ khác trong cùng khu vực, vậy về mặt kỹ thuật nó chẳng phải cũng là lưu trữ gắn qua mạng sao?
Về mặt nội bộ, họ có thể di chuyển volume từ máy chủ vật lý này sang máy chủ vật lý khác; cách họ làm khá thú vị, nhưng hiện chưa công khai nhiều
Năm nay họ dự định sẽ đưa nó ra nhiều hơn
Fly Volumes định kỳ sao lưu sang block storage ngoài mạng, và cũng sẽ sớm có thêm thông báo liên quan
Điểm cần hiểu cơ bản là Fly Volumes không phải lưu trữ SAN, cũng không phải loại lưu trữ vốn ổn định như S3
Bên trong Fly Machines, nó chỉ hiện ra như một filesystem ext4 đơn giản; nếu cần độ ổn định, độ bền và sao chép, bạn phải cung cấp ở tầng ứng dụng
Fly Postgres hoạt động như một cụm bản sao đọc, và nếu cần thì bất kỳ bản sao nào cũng có thể tiếp quản vai trò writer leader, nên cách này là phù hợp
Đó cũng là lý do nếu bạn định tạo cụm Postgres một nút thì bảng điều khiển sẽ hiện một cảnh báo đỏ rất lớn
Có lẽ trong vài quý tới họ sẽ đưa ra các lựa chọn mới trên phổ độ ổn định và hiệu năng, nhưng có vẻ sẽ không phải kiểu tự vận hành trực tiếp ổ SAN chỉ để lộ block device theo kiểu iSCSI
Tôi thực sự ghét mô hình giá của cả hai công ty này
Một đầu là Supabase, với kiểu gói phân tầng như các nền tảng dành cho lập trình viên kiểu Vercel, được cấu trúc để khiến bạn trả nhiều hơn mức sử dụng thực tế
Đầu kia là Fly, với kiểu tính giá quá vụn vặt theo giây, theo bộ nhớ, theo CPU như Lambda, nên có khả năng bạn lại trả quá ít và bị giảm hiệu năng
Khi đã có thứ như Cloudflare Workers, tôi không hiểu vì sao lại chọn một trong hai. Tại sao vẫn còn muốn phải lo chuyện mở rộng?
Cũng có vẻ khó là Cloudflare sẽ cung cấp Postgres thực sự. Triết lý của Cloudflare là mọi thứ họ triển khai đều được triển khai trên toàn cầu, trong khi cơ sở dữ liệu quan hệ buộc phải có một máy chủ đơn làm nguồn chân lý
Dĩ nhiên, tôi rất mong điều đó được chứng minh là sai
Giá theo tháng của Fly khá dễ hiểu và hoàn toàn không giống Lambda. Nếu phải nói thì mô hình giá của Cloudflare Workers mới gần Lambda hơn