Also available in: 日本語

About a year and a half has passed since Aurora DSQL was unveiled at re:Invent 2024. It's become a pretty convenient database service: you get a RDBMS that speaks SQL with the ease of use of DynamoDB, without the design difficulty that usually comes with purpose-built databases like DynamoDB. Yet, even after all this time, real-world case studies are still scarce.

That's not surprising. While DSQL speaks SQL, its runtime behaves more like a DynamoDB-style database than vanilla PostgreSQL, and that's the trade-off you pay for that ease of use. Put differently, compatibility with PostgreSQL stops at the protocol level; the behavior isn't compatible. That seems to be the sticking point that makes migrating an existing PostgreSQL application difficult to do as-is. On that front, other PostgreSQL-compatible serverless databases like Neon arguably have the edge, even though their pricing model differs.

In this post, I'll walk through where we've hit friction and how we've worked around it, based on our experience actually adopting Aurora DSQL as the database for a Rails application we've been building from scratch since late last year.

This is an English translation of the Japanese blog post from the RubyKaigi NOC team, primarily written by @hanazuki. This translation is done by @sorah also from the team, prepared for the IETF community and broader audience interested in IPv6-mostly network deployments.

The RubyKaigi NOC team is providing Wi-Fi at conferences on the Ruby programming language in Japan, including RubyKaigi 2025 and Kaigi on Rails 2025. Starting this year, we began experimenting¹ IPv6-mostly networks instead of traditional IPv4/IPv6 dual-stack networks.

At RubyKaigi 2025 held in April, we encountered interoperability issues with Apple devices². Following the conference, we conducted additional tests to diagnose these issues and developed workarounds. Apple released macOS 26 Tahoe and iOS 26 in September, shortly before Kaigi on Rails 2025, showing behavioral improvements addressing the discovered issues.

This blog post documents the issues we discovered with macOS 15 Sequoia and iOS 18, the workarounds we implemented, and verifies the behavioral changes in the newly released macOS 26 Tahoe and iOS 26.

In conclusion, the major issues appear to have been resolved in macOS 26 Tahoe and iOS 26. However, to support connectivity without issues for devices on previous releases, we implemented a workaround at Kaigi on Rails 2025, which successfully prevented the issues from occurring. Continue reading for details on the issues and workarounds.

I prefer a remotely-accessible Linux box for development and any terminal-required work and spend most of my time on it. Recently I changed my job, but still have the same preference. At my previous employer, I ran a physical Linux workstation in office, and used Mac laptop and Windows desktop to access via corporate network.

At my new employer, having a Linux box was easy, but accessing it remotely posed a challenge. First, my new office lacks external access capability. Second, I picked up a Windows workstation for desktop environment and placed it in my home; My Linux box runs in Hyper-V instead of on physical hardware. This choice was made to keep expenses minimal (as a new employee) while satisfying my needs: having a Windows desktop in my primary work location (home), plus Mac laptop for remote and office, and Linux box for my dev work.

Fortunately, my employer was experiencing productivity issues on accessing internal resources via AWS Client VPN. I recently introduced Twingate, which I love and which worked great at my previous company for accessing internal resources - including my Linux workstation. So I can now do the same at my new employer by just spinning up a Twingate connector on the Linux box. However, as a connector technically can send packets to arbitrary destinations - would allow free access to admins, I didn't want to allow that to my admin colleagues; even though I trust them.

I achieved a restricted Twingate connector setup by combining netns, nftables, and systemd tricks. Continue reading for deployment details.

We usually change SSH port to different one for some security. Like when provisioning server from official Ubuntu AMI, connecting to a server fails using same ssh_config without specifying port 22 explicitly.

the following quick hack task adds Port line on /etc/ssh/sshd_config then restart sshd. This works on Ubuntu 14.04 trusty. Change ensure_cmd for your system. Note that this adds listening port, not replacing port. More modification on sshd_config will be done via provisioning tool which run after this simple task, so this task only does simple one.

I recommend to make this task runs before deploy task.

task :ensure_ssh_port do
  on roles(:app) do |srv|
    user = srv.ssh_options[:user]
    port = srv.ssh_options[:port] || Net::SSH::Config.for(srv.to_s)[:port]
    unless port
      puts "ensure_ssh_port(#{srv}, #{port}): skip"
      next
    end

    puts "ensure_ssh_port(#{srv}, #{port}): start"

    user_opt = user ? "#{user}@" : ""

    if system(*%W(ssh -T -p #{port} #{user_opt}#{srv} true), err: File::NULL, out: File::NULL)
      puts "ensure_ssh_port(#{srv}, #{port}): ok"
      execute "echo '#{srv} port ensured'"
      next
    end

    unless system(*%W(ssh -T -p 22 #{user_opt}#{srv} true), err: File::NULL, out: File::NULL)
      abort "Couldn't connect #{user_opt}#{srv} with both port 22 and #{port}"
    end

    puts "ensure_ssh_port(#{srv}, #{port}): port 22 ok, changing sshd"

    ensure_cmd = "ssh -T -p 22 #{user_opt}#{srv} \"sudo sh -c 'echo Port #{port} >> /etc/ssh/sshd_config && service ssh restart'\""
    puts "ensure_ssh_port(#{srv}, #{port}): $ #{ensure_cmd}"
    system(ensure_cmd) or raise 'failed to ensure'

    execute "echo '#{srv} port ensured'"
  end
end