earayu

Two ways to use it 1. Run the agent inside the sandbox Use Treadstone when the agent itself should live in the isolated environment and keep working there over time.

2. Use the sandbox as a tool Use Treadstone when your agent runs elsewhere, but needs an isolated environment it can create, inspect, and drive on demand.

In practice, that means an agent can:

create and manage sandboxes over the CLI, REST API, or Python SDK operate what is running inside them through shell, file, browser, HTTP/WebSocket, and MCP hand the same browser session to a human when review or takeover matters

Treadstone is an agent-native sandbox platform for longer-running AI work. You can run agents inside isolated sandboxes, or treat sandboxes as tools that agents call on demand. Each sandbox is built around an all-in-one runtime: code execution, shell, file system, browser-facing surfaces, MCP, and long-running state.

Treadstone is open source, self-hostable, and built on Kubernetes.

Maintaining databases is painful, so ApeRAG uses kubeblocks for all these databases.

Yes, ApeRAG uses all these databases.

Location: China Remote: Yes

Willing to relocate: Yes

Technologies: Golang, Java, Python, Database Development, Kubernetes, Cloud, Backend, SQL, AI

Résumé/CV: https://earayu.github.io/about

Email: earayu@gmail.com

LinkedIn: https://www.linkedin.com/in/guanghui-yu-6b0784239/

I'm a database kernel engineer with business development experience, contributing to WeScale database proxy with features like read-write splitting. Previously led DDL execution engine design at Alibaba's PolarDB-X team, and actively maintain WeSQL and KubeBlocks open source communities.

KubeBlocks is an open-source database operator that enables teams to easily deploy, manage and operate any database on Kubernetes. It provides a unified approach to database management, supporting various databases like MySQL, PostgreSQL, Redis, MongoDB and more with enterprise-grade features including high availability, backup & restore, and automated day-2 operations.

How about this: https://kubeblocks.io/

A Modern MySQL proxy that supports read-write-split, read-after-write-consistency, load balancing and OnlineDDL.

https://github.com/wesql/wescale

Using it for CI/CD purposes does not violate GitHub's Terms of Service.

yeah, you are right.

for example, don't use Actions as a content delivery network or as part of a serverless application, but a low benefit Action could be ok if it’s also low burden

Just as the wesql article states, Use Cases is Not Recommended For:

- Long-term database hosting or production workloads. - Maintaining an always-on public database endpoint. - Circumventing GitHub Actions usage policies.

I was thinking about EC2's default instance storage - it's ephemeral and gets wiped when you restart or stop the instance. Without paying for EBS volumes, EC2's storage is non-persistent by design.

just use it for CI/CD

GitHub Actions is completely free, and you can always use free S3-compatible storage like Cloudflare R2, making the entire setup cost nothing.

VPS has two main drawbacks:

Many don't guarantee persistent disk storage It's not ideal for CI/CD scenarios where you need ephemeral databases for testing But you're right - if you need a simple, always-on database, a $5 VPS might be a good choice.

Yep, GitHub Actions isn't meant for production deployment - it's a CI/CD service with a 6-hour limit per run.

But that's the cool thing about WeSQL - you can run it anywhere! Just fire it up like any other container. For production, throw it on ECS/EKS and you're good to go.

Sure. That's the fascinating aspect of WeSQL database - its compute-storage separation allows you to run the database anywhere while data persists in S3.

You can shut down the compute service and restart it anywhere else - the data will simply restore from S3.

nice

When I was extroverted, I tend to be willing to take more responsibilities, showing concern for others, being optimistic. In the opposite, I tend to take less responsibilities, easily become anxious and always worried about the future.

Location: UTC+8, China

Remote: YES

Willing to relocate: Maybe

Technologies: Database、Database Kernel、Java、Go、Web Development、Kubernetes

Résumé/CV:https://earayu.github.io/resume/resume2024.pdf

Email:earayu@gmail.com

I am a software engineer, most of the time, PMs are just make my work harder.

As for the transactional nature of DDL - MySQL does not support using DDL in transactions (each DDL is a separate transaction).

Online DDL is typically executed asynchronously. This has the benefit of making DDL more manageable and not impact the availability of the database due to MDL locks or consuming too many resources. After executing an Online DDL, a JobId will be returned. Subsequently, the progress can be checked using the JobId, and some control commands can also be executed, such as suspending, resuming, or canceling.

https://github.com/wesql/wescale/blob/main/doc%2Fblogs%2FPer...

Integrating WeSQL WeScale as a MySQL proxy may initially increase network latency due to additional round trips. However, as the load scales, it matches the throughput and latency of a direct MySQL connection. Connection multiplexing allows WeSQL WeScale to sustain high throughput under heavy loads, unlike MySQL, which may suffer performance drops due to too many connections consuming buffer pool memory. With read-write splitting enabled, WeSQL WeScale continues to scale linearly in throughput beyond MySQL's limits as test threads increase. The memory footprint of WeSQL WeScale is minimal in comparison to MySQL, and it only adds about one-third to the CPU overhead. For increasing queries per second (QPS), WeSQL WeScale's read-write splitting and horizontal scaling is more cost-effective than MySQL's vertical scaling.